From owner-v6ops@ops.ietf.org  Mon Nov  1 05:15:08 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11320
	for <v6ops-archive@lists.ietf.org>; Mon, 1 Nov 2004 05:15:07 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1COZ9v-000DPa-OI
	for v6ops-data@psg.com; Mon, 01 Nov 2004 10:11:31 +0000
Received: from [193.180.251.47] (helo=penguin.ericsson.se)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1COZ9u-000DPM-DM
	for v6ops@ops.ietf.org; Mon, 01 Nov 2004 10:11:30 +0000
Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121])
	by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id iA1ABTfM018951
	for <v6ops@ops.ietf.org>; Mon, 1 Nov 2004 11:11:29 +0100 (MET)
Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211);
	 Mon, 1 Nov 2004 11:11:29 +0100
Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id VJSMY3W0; Mon, 1 Nov 2004 11:11:29 +0100
Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <J4ND1CR5>; Mon, 1 Nov 2004 11:11:29 +0100
Message-ID: <C26BB8276599A44B85D52F9CE41035E1050B97E4@esealnt944.al.sw.ericsson.se>
X-Sybari-Trust: 5018411c bfd556f1 fc586638 00000139
From: "Karen E. Nielsen (AH/LMD)" <karen.e.nielsen@ericsson.com>
To: v6ops@ops.ietf.org
Subject: RE: I-D ACTION:draft-ietf-v6ops-assisted-tunneling-requirements-0
	1.txt
Date: Mon, 1 Nov 2004 11:11:28 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
X-OriginalArrivalTime: 01 Nov 2004 10:11:29.0220 (UTC) FILETIME=[276A7040:01C4BFFB]
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

One comment:

The following paragraph of Section 1 should be made clearer,
I think.

"Contrary to automatic tunneling mechanism where the IPv4 address is
   embedded inside the IPv6 address, no special format are imposed on
   the IPv6 address used in assisted tunneling.  Prefix delegation is
   also possible.  As the addressing space used during the transition to
   native remains the same, the customer routing, filtering, accounting
   stay the same, and there is no need to maintain any kind of relay."

If the intended meaning is to say that the IPv6 addresses used during transition
must be usable also when the users has moved to native, this should be made clearer
here as well as in Section 4.1. 

Again if the above is the intended meaning, it is valid of course to note that 
that this preclude mechanisms which rely on special encoding of the underlying
Ipv4 in the Ipv6 addresses.

BR, Karen

> -----Original Message-----
> From: i-d-announce-bounces@ietf.org
> [mailto:i-d-announce-bounces@ietf.org]On Behalf Of
> Internet-Drafts@ietf.org
> Sent: Friday, October 22, 2004 10:11 PM
> To: i-d-announce@ietf.org
> Cc: v6ops@ops.ietf.org
> Subject: I-D
> ACTION:draft-ietf-v6ops-assisted-tunneling-requirements-01.txt
> 
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> This draft is a work item of the IPv6 Operations Working 
> Group of the IETF.
> 
> 	Title		: Goals for Registered Assisted Tunneling
> 	Author(s)	: F. Parent, et al.
> 	Filename	: 
> draft-ietf-v6ops-assisted-tunneling-requirements-01.txt
> 	Pages		: 14
> 	Date		: 2004-10-22
> 	
> This document defines requirements for a tunnel set-up protocol that
>    could be used by an ISP to jumpstart its IPv6 offering to its
>    customers by providing them IPv6 connectivity through tunneling.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-v6ops-assisted-
tunneling-requirements-01.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-v6ops-assisted-tunneling-requirements-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-v6ops-assisted-tunneling-requirements-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.



From owner-v6ops@ops.ietf.org  Mon Nov  1 09:00:10 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04121
	for <v6ops-archive@lists.ietf.org>; Mon, 1 Nov 2004 09:00:10 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1COcgw-000AUj-Rf
	for v6ops-data@psg.com; Mon, 01 Nov 2004 13:57:50 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1COcgv-000ATy-HY
	for v6ops@ops.ietf.org; Mon, 01 Nov 2004 13:57:49 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id iA1DvhM13680;
	Mon, 1 Nov 2004 15:57:43 +0200
Date: Mon, 1 Nov 2004 15:57:43 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: v6ops@ops.ietf.org
Subject: final v6ops agenda for IETF61
Message-ID: <Pine.LNX.4.61.0411011556270.13579@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

Wednesday 10th November -- 0900-1130
====================================
(The date & time is still tentative.)

*** CRITICAL PATH ACTIVITIES ***

Introduction, agenda bashing, document status - 10 mins, Chairs/Savola
   - Scribes! (Jabber also?)

Enterprise Analysis Discussion, 15 mins, Bound
  - draft-ietf-v6ops-ent-analysis-00.txt
  - GOAL: discuss issues, so that the revision can be WGLC'ed

Generic Zero-Configuration Tunneling, 15 mins, ???
  - http://www.v6ops.euro6ix.net/ietf/draft-suryanarayanan-v6ops-zeroconf-reqs-01.txt
  - GOAL: Present and discuss WG LC issues

Goals for Zero-Configuration Tunneling in 3GPP, 10 mins, Nielsen
  - draft-nielsen-v6ops-3GPP-zeroconf-goals-00.txt>
  - present the 3GPP tunneling case and the technical goals/requirements
  - GOAL: To highlight the particularities of the 3GPP case

Assisted Registered Tunneling Requirements - 10 mins, Parent
  - draft-ietf-v6ops-assisted-tunneling-requirements-01.txt
  - go through open issues, discuss
  - GOAL: discuss WGLC issues, if any

Discussion of the way forward - 15 mins, Chairs/ADs
  - GOAL: discuss and get consensus on how to proceed from here

*** OTHER IMPORTANT WORK ***

IPv6 Network Architecture Protection, 10 mins, Van de Velde
  - draft-vandevelde-v6ops-nap-00.txt
  - GOAL: introduce and start the discussion about v4 NAT alternatives in IPv6

Reason to Deprecate NAT-PT, 15 mins, Davies
  - draft-aoun-v6ops-natpt-deprecate-00.txt
  - GOAL: 5 mins presentation, 10 mins trying to decide next steps

ISP IPv6 Deployment Scenarios in Broadband Access Networks, 15 mins, Popoviciu
  - draft-asadullah-v6ops-bb-deployment-scenarios-01.txt
  - GOAL: get feedback; gauge interest and the direction

IPv6 Fix: an activity to solve barriers to IPv6 transition, 7-10 mins, Tatuya
  - A new WIDE project to fix practical IPv6 deployment issues
  - GOAL: inform the WG of activities, solicit the interested people

*** MAY BE SKIPPED IF RUNNING OUT OF TIME ***

Discussion of Teredo IETF LC comments, 5 mins, Huitema
  - draft-huitema-v6ops-teredo-02.txt
  - GOAL: describe and discuss the important IETF LC comments

IPv6 Security Overview - 5-7 mins, Davies
  - draft-savola-v6ops-security-overview-03.txt
  - GOAL: talk about differences, solicit more feedback

Things to think about when renumbering, 5-7 mins, Thompson
  - draft-chown-v6ops-renumber-thinkabout-00.txt
  - GOAL: introduce the draft, solicit feedback for next revision

IP Mobility Scenarios discussion, 5 mins, Someone?
  - draft-larsson-v6ops-mip-scenarios-00.txt ?
  - GOAL: update from the IP mobility scenarios/requirements discussion




From owner-v6ops@ops.ietf.org  Mon Nov  1 09:07:35 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04776
	for <v6ops-archive@lists.ietf.org>; Mon, 1 Nov 2004 09:07:35 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1COcqG-000D4h-Gz
	for v6ops-data@psg.com; Mon, 01 Nov 2004 14:07:28 +0000
Received: from [213.172.48.142] (helo=consulintel.es)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1COcq8-000D3o-J7
	for v6ops@ops.ietf.org; Mon, 01 Nov 2004 14:07:21 +0000
Received: from [10.10.10.102] ([217.126.187.160])
	by consulintel.es (consulintel.es [127.0.0.1])
	(MDaemon.PRO.v7.2.0.R)
	with ESMTP id md50000543110.msg
	for <v6ops@ops.ietf.org>; Mon, 01 Nov 2004 15:12:40 +0100
User-Agent: Microsoft-Entourage/10.1.4.030702.0
Date: Sun, 31 Oct 2004 23:02:24 +0100
Subject: Re: comments on draft-palet-v6ops-solution-tun-auto-disc-00.txt
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: <v6ops@ops.ietf.org>
Message-ID: <BDAB1F80.4D0C1%jordi.palet@consulintel.es>
In-Reply-To: <Pine.LNX.4.61.0410270917260.6443@netcore.fi>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Spam-Processed: consulintel.es, Mon, 01 Nov 2004 15:12:40 +0100
	(not processed: message from valid local sender)
X-MDRemoteIP: 217.126.187.160
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ops.ietf.org
Reply-To: jordi.palet@consulintel.es
X-MDAV-Processed: consulintel.es, Mon, 01 Nov 2004 15:12:46 +0100
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00,
	DATE_IN_PAST_12_24 autolearn=no version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Pekka, all,

Some comments below, in-line.

Regards,
Jordi


> De: Pekka Savola <pekkas@netcore.fi>
> Responder a: owner-v6ops@ops.ietf.org
> Fecha: Wed, 27 Oct 2004 10:11:06 +0300 (EEST)
> Para: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
> CC: v6ops@ops.ietf.org
> Asunto: Re: comments on draft-palet-v6ops-solution-tun-auto-disc-00.txt
> 
> Some comments below..
> 
> (Btw, as a couple of subjects were left in as 'waiting for more
> feedback', it would be useful to have some kind of issue tracker or
> web page, summary in the following drafts, or the like to keep track
> of comments which have been submitted but haven't been reflected..)
> 
> On Sun, 24 Oct 2004, JORDI PALET MARTINEZ wrote:
>>> Does the solution have to support complete 3rd parties, such as
>>> anycasting 6to4 relays now? (Remember that 6to4 relays are stateless,
>>> while the tunnel servers typically aren't, and this would cause
>>> additional implications on the mechanisms.)
>> 
>> As explained in the Case Studies section, is up to each ISP to decide if
>> they want to support external users or not.
> 
> Certainly, but remember that some of the solutions we're discussing
> are 'inter-domain', while some others are not (like ISATAP, a possible
> zero-conf tunneling solution).

Well, I should not look into existing solutions if I want to be fair ;-)
This WG probably should have been before the solutions but ...

In my opinion we can have an auto-discovery solution that work with both
inter-domain and intra-domain. Don't see the problem on that.

> 
> These two different kinds of mechanisms do have different kinds of
> requirements for the discovery process: certainly, something like 6to4
> is pretty likely to be completely different than the rest.  But we
> don't need an interdomain solution to 6to4 because we have one
> already...

I don't agree. If we provide an intra-domain solution for the 6to4
discovery, combined with the existing inter-domain one, this has a lot of
advantages, in getting 6to4 more useful (lower RTT) if this is available in
the domain where the client is attached. At the same, time we are providing
a unique solution that will work the same not just for 6to4, but also for
the rest of the mechanism.

Obviously, as co-author, I'm very convinced that this is a good solution ;-)

So, I think we really need to have some other opinions from the WG !

> 
>>> Does the solution have to support those customers which momentarily
>>> roam outside of their ISP's access network?  [E.g., as solution based
>>> on DNS records would probably still be at least partially applicable
>>> here]
>> 
>> From the users point of view, yes. Of course, users always need to rely into
>> available services, but if we don't provide this part of the solution, they
>> will never have it. Providing it, they might have it (up to the providers,
>> even if a few that with to provide the service).
> 
> But then you assume that the mechanism you're discovering supports
> this feature, which may not be true ?
> 
> My point is, that if the discovery is relatively simple, it could also
> be implemented (with just a couple of dozen or a hundred lines of
> code) in the mechanisms themselves, not a generic 'library' or the
> like.

Yes, that will be in an ideal world, to ask all the implementers to include
a few lines of code to support this, but that's not going to happen, I
think, so we propose a solution that not really requires that, because it
can be implemented as a higher layer to the existing code.

> 
>>> I'm concerned that because there is significantly smaller amount of
>>> incentive, and more technical challenges, for ISPs to deploy an
>>> inter-domain anycast solution for tunnel servers, so that it would not
>>> be actually usable for discovery.
>> 
>> I don't agree, 6to4 is working, and we are just extending the applicability
>> of 6to4 to other mechanisms.
> 
> You don't have to renumber your network when you happen to switch 6to4
> relay providers, either by manually or because the routing changes.
> That would be inevitable with other kinds of mechanisms.  Therefore
> such an interdomain anycast address would have limited applicability
> IMHO. (Only even marginally feasible if anycast was used just for
> discovery, and unicast used for real communication)

Renumbering is not an issue if you just need "connectivity" and you want to
have it as much automatically as possible.

And I guess this is the most normal case for today roaming users, those that
will be affected by renumbering when traveling.

I prefer making sure to get connectivity than anything else. Because if you
really require the same address all the time, and you don't care about
better performance, then you should use, for example TSP and all the time
the same TB, which is perfectly compatible with the proposed solution.

> 
>>>>> and 2)  the draft doesn't sufficiently describe the
>>>>> mechanism/protocol/implementation requirements, and how those
>>>>> interoperate with whatever the ISPs would deploy.
>>>> 
>>>> I'm not sure what do you mean here, but providing more details about DNS
>>>> SRV
>>>> RR and anycast seems to us out of the scope of this document. There are no
>>>> _new_ requirements for the ISP, neither the client, because we are using
>>>> existing mechanism (DNS and anycast).
>>> 
>>> No, I didn't mean that, but rather what mechanisms must be implemented
>>> in the mechanism or the host stack.  I'll try to explain below.
>> 
>> Ok. We can work on that in a new section, with concrete examples for
>> different mechanisms.
> 
> OK.
> 
>>> Maybe I did not write clearly enough, without assumptions.
>>> 
>>> Whether or not this discovery process is done in the host stack, or
>>> the transition mechanism, is relatively irrelevant.
>>> 
>>> However, it is VERY MUCH relevant to this draft WHAT must be
>>> implemented in the host stack or the mechanism to make these work.
>>> 
>>> For example, if the host would just implement DNS lookups and the ISP
>>> just anycast, discovery process should fail.
>> 
>> Understood now. The client must implement the complete picture, but not the
>> server. I'm about to finish an updated version of the document, and will
>> make sure this is clear.
> 
> Good to make it clear.
> 
> FWIW, I personally aren't that fond of the requirement that the
> protocols/mechanisms would have to implement everything -- because
> that would add complexity, and might have significant disadvantages
> (e.g., relating to the latency of the set-up, if you have to try e.g.
> 3 different methods sequentially).

Not really, because if your ISP is providing the service (ideal world) then
you will try only the 1st option. If not you got for the 2nd, and only look
for the 3rd if your ISP is not providing the service, but then we provide a
last resort option.

As many ISPs provide the service, then more often you will try less options,
which is good as an automatic "phase-out".

> 
>>>> We are using a single name for each protocol, so whatever is implemented in
>>>> the ISP, will work for the client. I think this provides complete
>>>> interoperability !
>>> 
>>> Yes, but you also specify the inter-domain anycast in addition to DNS
>>> lookups using SRV or A records.
>>> 
>>> Which ones must be supported in the client?  Which ones in the ISP?
>>> There are probably half a dozen non-interoperable combinations here.
>>> 
>>> Maybe your implicit assumption is that the client supports all of
>>> them: interdomain anycast, DNS with SRV, and DNS with A records, and
>>> maybe even DHCP to the boot -- and tries them in some particular
>>> order, and then it would just depend on what the ISP supports.
>>> 
>>> I don't have that assumption.  On the contrary, I think there must be
>>> a minimal set of approaches so that 1) very little is required to
>>> implement & deploy, and 2) there are as few interop problems as
>>> possible.
>> 
>> My point of view is that both the ability to resolve SRV/A and anycast are
>> already available today in all the clients, so making both as part of the
>> requirement, will not add actually any new requirements.
> 
> Having to look up both SRV and A records adds at least (and possibly
> more) one round-trip.  SRV requires the use of non-standard APIs AFAIR
> (e.g., getrrsetbyname), which may or may not be present.
> 
> And then there is inter-domain anycast..
> 

Anyway, have you really calculated how much time this sequence requires in
the worst case ? I really think this is imperceptible for the user, and good
if it ensures "final working conditions".

I believe that our investigation on SRV revealed that all the OSs that today
support IPv6, already support SRV, so not an issue.

Not sure if we want to put in the text concrete OS names ...

>>>>> semi-substantial
>>>>> ----------------
>>>>> 
>>>>>  On the other hand, shared anycast is also a very useful approach
>>>>>  since it can globally identify a specific service (TEP or transition
>>>>>  mechanism).
>>>>> 
>>>>> ==> I think you're assuming that anycast (shared-unicast) would be
>>>>> allocated
>>>>> an interdomain range, because otherwise it can't be globally identified.
>>>>> This doesn't need to be the case.
>>>> 
>>>> Our intend is to use the same prefix as for 6to4, for all the mechanisms
>>>> (so
>>>> we can allocate for example up to 254 new mechanisms, more than enough).
>>> 
>>> Uhh, I didn't quite understand: did you mean 192.88.99.2 for X, .3 for
>>> Y, .4 for Z, or "similar prefix as for 6to4", like 192.88.100.0/24 for
>>> X, .101.0/24 for Y, etc.
>>> 
>>> The former would definitely not work.
>> 
>> You're right. I was actually thinking in the option that you describe in
>> first place, but I now realize that precisely because that problem, we use a
>> prefix for 6to4, instead of just one address. So need to double-check if we
>> need to move to the 2nd way, or there is an alternative.
> 
> A prefix might be possible for some inter-domain services, but for
> those that aren't, IMHO it should be dropped completely.

Yes, you're right on this, very good point. For some mechanism that will not
work inter-domain, there is no need for the prefix.

Will fix the text on this in the next version.

> 
> And even for inter-domain, I don't think there are any which would
> need it: Teredo had it before, but it was removed due to review from
> routing people (because one would need to send packet with the anycast
> address as the source to pierce the NATs), or just as a discovery
> method.  For something like TSP, this wouldn't make sense because you
> could end up with different providers, with different prefixes.
> Again, this would only make marginal sense as 'discovery of the
> unicast address', not much else.
> 
> Hence, I'm not so sure that inter-domain anycast address is really
> needed now.

Well my conclusion then is that may be we need to think twice about
considering anycast for discovering the unicast address, but as I recall
that had the issue of making the implementation more complex, so may have
some trade off.

We will work on that and will come back on this point.

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



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






From owner-v6ops@ops.ietf.org  Mon Nov  1 09:07:40 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04803
	for <v6ops-archive@lists.ietf.org>; Mon, 1 Nov 2004 09:07:39 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1COcq0-000D2A-E1
	for v6ops-data@psg.com; Mon, 01 Nov 2004 14:07:12 +0000
Received: from [213.172.48.142] (helo=consulintel.es)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1COcpz-000D1k-0x
	for v6ops@ops.ietf.org; Mon, 01 Nov 2004 14:07:11 +0000
Received: from [10.10.10.102] ([217.126.187.160])
	by consulintel.es (consulintel.es [127.0.0.1])
	(MDaemon.PRO.v7.2.0.R)
	with ESMTP id md50000543107.msg
	for <v6ops@ops.ietf.org>; Mon, 01 Nov 2004 15:12:33 +0100
User-Agent: Microsoft-Entourage/10.1.4.030702.0
Date: Sun, 31 Oct 2004 20:06:36 +0100
Subject: Re: WG last call on tunneling scenarios
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: <v6ops@ops.ietf.org>
Message-ID: <BDAAF64C.4D0BA%jordi.palet@consulintel.es>
In-Reply-To: <Pine.LNX.4.61.0410291149220.9900@netcore.fi>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Spam-Processed: consulintel.es, Mon, 01 Nov 2004 15:12:33 +0100
	(not processed: message from valid local sender)
X-MDRemoteIP: 217.126.187.160
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ops.ietf.org
Reply-To: jordi.palet@consulintel.es
X-MDAV-Processed: consulintel.es, Mon, 01 Nov 2004 15:12:35 +0100
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00,
	DATE_IN_PAST_12_24 autolearn=no version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Pekka, all,

I agree with this decision, but I'm not sure if is fair enough.

Let me explain. In general I feel that there is too much secret discussions
among the ADs and the co-chairs. I never understood why this talks doesn't
happen within the WG mail exploder, to get other inputs, ideas, or whatever
from the WG. Even if you only get a couple of them, they might be useful.

So, I absolutely disagree with the way the decisions are being taken. This
is not consensus, is probably something closer to a semi-dictatorial
process, and don't take me wrong, you know that I don't have anything
personally against anyone, ADs and co-chairs included, but I prefer much
more being honest, open and clear. It seems to me that we somehow the WG is
getting driven to a very limited set of options.

More concretely, it's absolutely unacceptable in my opinion (even if I'm one
of the co-authors), that the 3GPP-zerocong is being prioritized while other
work, which has been around for longer time, is not treated the same way.

Last but not least, as a concrete example of this, I don't understand how we
can have pieces needed for those I-Ds which are not even considered as WG
items, like the tun-auto-disc and the solution document. If there is any
problem with those documents, please, speak up, otherwise the WG should be
asked for accepting them as WG items NOW.

Hopefully others in the WG mind something all this and have also an opinion.
Otherwise, is probably better that we stop the WG itself.

Regards,
Jordi


> De: Pekka Savola <pekkas@netcore.fi>
> Responder a: owner-v6ops@ops.ietf.org
> Fecha: Fri, 29 Oct 2004 11:51:23 +0300 (EEST)
> Para: v6ops@ops.ietf.org
> Asunto: WG last call on tunneling scenarios
> 
> (co-chair hats on)
> 
> Hello,
> 
> In the interest of moving forward from the tunneling requirements, we
> have discussed the situation with ADs, and will be proposing some
> actions.
> 
> One of these is getting a reasonable consensus on the requirements for
> zero-config and registered assisted tunneling.  In order to be able to
> discuss whether existing solutions fit the requirements, how they need
> to be modified, or which kind of new solutions should be specified,
> we'll have to get the requirements to a closure.
> 
> But finishing the requirements will have to happen fast: in the event that
> there are issues for which there is no consensus, it'll be better to just
> document both sides of the argument fairly, and move on and evaluate the
> tradeoffs when selecting or specifying the solution(s).
> 
> In order to achive this, we propose adopting the following as WG items:
> 
> http://www.ietf.org/internet-drafts/draft-nielsen-v6ops-3GPP-zeroconf-goals-00
> .txt
> http://www.v6ops.euro6ix.net/ietf/draft-suryanarayanan-v6ops-zeroconf-reqs-01.
> txt
> 
> Please speak up if you object to this.
> 
> In addition, we are issuing WG last call (for Informational) for:
> 
> draft-nielsen-v6ops-3GPP-zeroconf-goals-00.txt
> draft-suryanarayanan-v6ops-zeroconf-reqs-01.txt
> draft-ietf-v6ops-assisted-tunneling-requirements-01.txt
> 
> Please send the comments on the list, but specify clearly which document
> you're 
> commenting on.  Now is the last chance to speak up!
> 
> The WG last call expires on Monday, 8th November (the IETF week).
> 
> Pekka & Jonne
> co-chairs
> 
> 



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






From owner-v6ops@ops.ietf.org  Mon Nov  1 12:39:59 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08012
	for <v6ops-archive@lists.ietf.org>; Mon, 1 Nov 2004 12:39:59 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1COg6G-000PO8-T5
	for v6ops-data@psg.com; Mon, 01 Nov 2004 17:36:12 +0000
Received: from [193.252.22.21] (helo=mwinf1009.wanadoo.fr)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1COg6C-000PNj-Ri
	for v6ops@ops.ietf.org; Mon, 01 Nov 2004 17:36:09 +0000
Received: from me-wanadoo.net (localhost [127.0.0.1])
	by mwinf1009.wanadoo.fr (SMTP Server) with SMTP id E761318000BF
	for <v6ops@ops.ietf.org>; Mon,  1 Nov 2004 18:36:07 +0100 (CET)
Received: from Rmi (APuteaux-105-1-3-76.w80-11.abo.wanadoo.fr [80.11.85.76])
	by mwinf1009.wanadoo.fr (SMTP Server) with SMTP id 621A218001EF
	for <v6ops@ops.ietf.org>; Mon,  1 Nov 2004 18:36:07 +0100 (CET)
Message-ID: <003e01c4c039$46e506e0$0200a8c0@Rmi>
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= <remi.despres@wanadoo.fr>
To: "v6ops" <v6ops@ops.ietf.org>
Subject: A Unified 4to6 Transition Model (I-D project too late for IETF publication) 
Date: Mon, 1 Nov 2004 18:35:53 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit

Hi,

At http://perso.wanadoo.fr/remi.despres/4to6.htm you will find
an I-D project which arrived too late to be on the
IETF site for the November meeeting. (in txt, doc, and PDF target file to
be copied)

Its subject is a Unified Model, named 4to6,  for the IPv4 to IPv6
transition.

The innovative material it brings is believed to be important to facilitate
transition to IPv6, and to be therefore very relevant to the work of v6ops.

In particular, applicability of the new model to 3GPP, although not
explicitely covered, is expected .

Although late availability of the document didn't permit to have a slot in
the draft agenda, I hope to have exchanges of views in Washington with those
who are interested (or even before by e-mail).

productive contacts.


Regards,

Rémi Després




From owner-v6ops@ops.ietf.org  Mon Nov  1 13:33:27 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15592
	for <v6ops-archive@lists.ietf.org>; Mon, 1 Nov 2004 13:33:26 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1COgyH-0006Fd-LS
	for v6ops-data@psg.com; Mon, 01 Nov 2004 18:32:01 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1COgy2-0006Cm-AJ
	for v6ops@ops.ietf.org; Mon, 01 Nov 2004 18:31:46 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id iA1IVgr19962;
	Mon, 1 Nov 2004 20:31:42 +0200
Date: Mon, 1 Nov 2004 20:31:42 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
cc: v6ops@ops.ietf.org
Subject: WG process etc. [Re: WG last call on tunneling scenarios]
In-Reply-To: <BDAAF64C.4D0BA%jordi.palet@consulintel.es>
Message-ID: <Pine.LNX.4.61.0411012012560.19155@netcore.fi>
References: <BDAAF64C.4D0BA%jordi.palet@consulintel.es>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

As your reply seems to have been more about the overall process, 
rather than these particular documents themselves, I've renamed the 
thread.

Let's try to keep these issues separate; if you have specific comments 
about the drafts themselves, those would obviously also be appreciated 
(under the original thread).

In a slightly different order,

On Sun, 31 Oct 2004, JORDI PALET MARTINEZ wrote:
> I agree with this decision, but I'm not sure if is fair enough.
>
> Let me explain. In general I feel that there is too much secret discussions
> among the ADs and the co-chairs. I never understood why this talks doesn't
> happen within the WG mail exploder, to get other inputs, ideas, or whatever
> from the WG. Even if you only get a couple of them, they might be useful.
>
> So, I absolutely disagree with the way the decisions are being taken. This
> is not consensus, is probably something closer to a semi-dictatorial
> process, and don't take me wrong, you know that I don't have anything
> personally against anyone, ADs and co-chairs included, but I prefer much
> more being honest, open and clear. It seems to me that we somehow the WG is
> getting driven to a very limited set of options.
[...]
> Last but not least, as a concrete example of this, I don't understand how we
> can have pieces needed for those I-Ds which are not even considered as WG
> items, like the tun-auto-disc and the solution document. If there is any
> problem with those documents, please, speak up, otherwise the WG should be
> asked for accepting them as WG items NOW.

Just to be clear, could you articulate clearly what you believe are 
the concrete problems and/or what you believe would be the fixes to 
these problems?  Either on or off-list as you feel appropriate.

My interpretation of what you wrote seems to be:

  1. you'd wish to have more dialogue on the list on the way WG is 
managed

  2. as a particular point of 1), you'd wish to have more documents 
(e.g., draft-palet-tun-auto-disc, draft-palet-solution-tun-auto-disc) 
be called out whether they could be WG documents.

As for 1), yes, that's the goal, as far as it seems reasonable.  And 
one can always ask, and suggest improvements... And as for 2), that 
has been a priorization choice which was discussed at IETF60.  The 
reasons may not have been made sufficiently clear, but at least it was 
offered for public debate :)

More discussion is good, but I'd also like for us all to keep in mind 
that at least I personally would rather be concentrating on technical 
work rather than having lengthy debates on what should or should not 
be done in the WG, or in what order and in what manner.  Granted, 
those discussions are likely necessary now and then, but hopefully we 
should concentrate more on 'doing' rather than 'talking about doing' 
:).

> More concretely, it's absolutely unacceptable in my opinion (even if I'm one
> of the co-authors), that the 3GPP-zerocong is being prioritized while other
> work, which has been around for longer time, is not treated the same way.

I'm not sure if it's clear what you refer to here.  3GPP isn't treated 
specially AFAIK, in the sense that its WG adoption etc. is done at the 
same time as for the rest.

Maybe you're referrring to the fact that the 3GPP requirements are 
documented in a separate document, not as part of the generic 
requirements document?  The reason is mostly historical, as you know, 
but if people in the WG think that these should not be in the separate 
documents, now is the right time to speak up!

(Follow-ups to this should probably go back in the original thread!)

-- 
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 owner-v6ops@ops.ietf.org  Mon Nov  1 14:51:01 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22495
	for <v6ops-archive@lists.ietf.org>; Mon, 1 Nov 2004 14:51:00 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1COiAe-000FHi-P3
	for v6ops-data@psg.com; Mon, 01 Nov 2004 19:48:52 +0000
Received: from [213.172.48.142] (helo=consulintel.es)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1COiAX-000FDb-1X
	for v6ops@ops.ietf.org; Mon, 01 Nov 2004 19:48:45 +0000
Received: from [10.10.10.102] ([217.126.187.160])
	by consulintel.es (consulintel.es [127.0.0.1])
	(MDaemon.PRO.v7.2.0.R)
	with ESMTP id md50000543328.msg
	for <v6ops@ops.ietf.org>; Mon, 01 Nov 2004 20:54:06 +0100
User-Agent: Microsoft-Entourage/10.1.4.030702.0
Date: Mon, 01 Nov 2004 20:48:34 +0100
Subject: Re: WG process etc. [Re: WG last call on tunneling scenarios]
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: <v6ops@ops.ietf.org>
Message-ID: <BDAC51A2.4D257%jordi.palet@consulintel.es>
In-Reply-To: <Pine.LNX.4.61.0411012012560.19155@netcore.fi>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Spam-Processed: consulintel.es, Mon, 01 Nov 2004 20:54:06 +0100
	(not processed: message from valid local sender)
X-MDRemoteIP: 217.126.187.160
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ops.ietf.org
Reply-To: jordi.palet@consulintel.es
X-MDAV-Processed: consulintel.es, Mon, 01 Nov 2004 20:54:10 +0100
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Pekka, all,

Thanks for your reply.

Your interpretation about my email seems to me correct, see below in-line.

Regards,
Jordi


> De: Pekka Savola <pekkas@netcore.fi>
> Responder a: owner-v6ops@ops.ietf.org
> Fecha: Mon, 1 Nov 2004 20:31:42 +0200 (EET)
> Para: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
> CC: v6ops@ops.ietf.org
> Asunto: WG process etc. [Re: WG last call on tunneling scenarios]
> 
> As your reply seems to have been more about the overall process,
> rather than these particular documents themselves, I've renamed the
> thread.
> 
> Let's try to keep these issues separate; if you have specific comments
> about the drafts themselves, those would obviously also be appreciated
> (under the original thread).
> 
> In a slightly different order,
> 
> On Sun, 31 Oct 2004, JORDI PALET MARTINEZ wrote:
>> I agree with this decision, but I'm not sure if is fair enough.
>> 
>> Let me explain. In general I feel that there is too much secret discussions
>> among the ADs and the co-chairs. I never understood why this talks doesn't
>> happen within the WG mail exploder, to get other inputs, ideas, or whatever
>> from the WG. Even if you only get a couple of them, they might be useful.
>> 
>> So, I absolutely disagree with the way the decisions are being taken. This
>> is not consensus, is probably something closer to a semi-dictatorial
>> process, and don't take me wrong, you know that I don't have anything
>> personally against anyone, ADs and co-chairs included, but I prefer much
>> more being honest, open and clear. It seems to me that we somehow the WG is
>> getting driven to a very limited set of options.
> [...]
>> Last but not least, as a concrete example of this, I don't understand how we
>> can have pieces needed for those I-Ds which are not even considered as WG
>> items, like the tun-auto-disc and the solution document. If there is any
>> problem with those documents, please, speak up, otherwise the WG should be
>> asked for accepting them as WG items NOW.
> 
> Just to be clear, could you articulate clearly what you believe are
> the concrete problems and/or what you believe would be the fixes to
> these problems?  Either on or off-list as you feel appropriate.
> 
> My interpretation of what you wrote seems to be:
> 
> 1. you'd wish to have more dialogue on the list on the way WG is
> managed

Yes, that should be a must ! I never understood those "secret" conversations
among the ADs and the co-chairs that lead to decisions, which in my opinion
belong to the community, the WG.

> 
> 2. as a particular point of 1), you'd wish to have more documents
> (e.g., draft-palet-tun-auto-disc, draft-palet-solution-tun-auto-disc)
> be called out whether they could be WG documents.

Yes, I will say those documents are in a very good shape, and have the same
right to be considered WG items as many others.

> 
> As for 1), yes, that's the goal, as far as it seems reasonable.  And
> one can always ask, and suggest improvements... And as for 2), that

Is difficult to ask and suggest improvements when the previous conversations
are kept secret. Is difficult to provide comments without a concrete and
very clear rationale behind the decisions. The openness should come fist
from your side ;-)

> has been a priorization choice which was discussed at IETF60.  The
> reasons may not have been made sufficiently clear, but at least it was
> offered for public debate :)

That's why I'm asking for ;-). The discussion in IETF60 was again after some
close and "secret" talks, and this is a big part of the issue and problem.

If I look into the chapter, which is the only "legally valid framework" for
our work and for the decisions, I see a lot of operational works that are
being excluded from becoming WG items (even just ask the WG for it), which
is very unfair, and "legally against our own chapter". The decisions are
being taken in an unbalanced way, in my opinion.

> 
> More discussion is good, but I'd also like for us all to keep in mind
> that at least I personally would rather be concentrating on technical
> work rather than having lengthy debates on what should or should not
> be done in the WG, or in what order and in what manner.  Granted,
> those discussions are likely necessary now and then, but hopefully we
> should concentrate more on 'doing' rather than 'talking about doing'
> :).

Agree, but in general I see the WG (as a whole) not very proactive, and I'm
wondering if some of us are becoming so upset in the way this is being
driven, that we are just giving up.

Quick though (which could be a natural human reaction): Why I need to put
more effort on this WG if work that are clearly within the chapter are not
being considered, despite the lot of hours behind that work ?

> 
>> More concretely, it's absolutely unacceptable in my opinion (even if I'm one
>> of the co-authors), that the 3GPP-zerocong is being prioritized while other
>> work, which has been around for longer time, is not treated the same way.
> 
> I'm not sure if it's clear what you refer to here.  3GPP isn't treated
> specially AFAIK, in the sense that its WG adoption etc. is done at the
> same time as for the rest.

I recall Erik already commented about this ... I think even there was some
official request from 3GPP. I'm not opposing to that, but wondering if this
is the correct way we should act on those request, and what are the
consequences about that in the future towards other similar requests from
other groups.

On the other way around, I perfectly understand that industry is leading and
some non-standards are becoming de facto standards, which is not good.
That's why we need to work faster and in parallel instead of in serial and
slow mode. If the WG is not commenting or providing inputs, but there are no
objections either, the work should be standardized.

> 
> Maybe you're referrring to the fact that the 3GPP requirements are
> documented in a separate document, not as part of the generic
> requirements document?  The reason is mostly historical, as you know,
> but if people in the WG think that these should not be in the separate
> documents, now is the right time to speak up!

No, it was just an example. Nothing against this specific document, but is a
good example of the way the WG, and in general IETF is doing. How is
possible we have a document for a 3GPP-zeroconfiguration that we do during
the past meeting, and has been prioritized in such way, and other works
aren't treated the same way ?

Also, if there was a 3GPP request (may be I'm wrong about this), why this
has not been published openly in the IETF exploders, or web page or whatever
?

> 
> (Follow-ups to this should probably go back in the original thread!)
> 
> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> 
> 



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






From owner-v6ops@ops.ietf.org  Mon Nov  1 15:29:04 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27268
	for <v6ops-archive@lists.ietf.org>; Mon, 1 Nov 2004 15:29:04 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1COimm-000KRH-W4
	for v6ops-data@psg.com; Mon, 01 Nov 2004 20:28:16 +0000
Received: from [161.114.64.105] (helo=zmamail05.zma.compaq.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1COiml-000KR1-P2
	for v6ops@ops.ietf.org; Mon, 01 Nov 2004 20:28:16 +0000
Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186])
	by zmamail05.zma.compaq.com (Postfix) with ESMTP id 50236CC7C;
	Mon,  1 Nov 2004 15:28:15 -0500 (EST)
Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211);
	 Mon, 1 Nov 2004 15:28:15 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: WG process etc. [Re: WG last call on tunneling scenarios]
Date: Mon, 1 Nov 2004 15:28:18 -0500
Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B07A4D4B7@tayexc13.americas.cpqcorp.net>
Thread-Topic: WG process etc. [Re: WG last call on tunneling scenarios]
Thread-Index: AcTATFFTysHKDUdxTNSsSspCAVrpmQAAQqJw
From: "Bound, Jim" <jim.bound@hp.com>
To: <jordi.palet@consulintel.es>, <v6ops@ops.ietf.org>
X-OriginalArrivalTime: 01 Nov 2004 20:28:15.0090 (UTC) FILETIME=[50A21520:01C4C051]
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

Jordi,

>On the other way around, I perfectly understand that industry is
leading and some non-standards are=20
>becoming de facto standards, which is not good.
>That's why we need to work faster and in parallel instead of in serial
and slow mode. If the WG is not=20
>commenting or providing inputs, but there are no objections either, the
work should be standardized.

This is your confusion and the IETF changed I think about 18 months ago
or when we killed A6.  Specs cannot go forward from silence and that is
now true in all IETF WGs I know of in the IETF.  I first ran into this
in DHCPv6 working with Ralph as Chair many years ago.  I did not like it
at first and did not get it.  Then we were able to get the engineers to
comment on DHCPv6 and made the spec 10 times as strong and solid
consensus.  So now I am a firm believer in silence is no good as metric
to move a spec forward.  Zero conf work had lots of mail thread
discussions and appears to be valid to accept as work item within the
IETF.  Bottom line is the Chairs have not broken any rule but enforcing
the rule.  Also sometimes the WG is just maxed.  For example we did not
get input as fast as we needed it for Enterprise Analysis but then we go
so much I am still parsing it as Ent Analysis editor.  I don't think
there is any scientific method to this at all the longer I am around. =20

There is also no secret discussions that is just absurd.  Is it possible
the ADs and Chairs individually don't support specific work, sure, but
that's another matter and their right, and fair too.  The objective is
to get the WG excited technically about specific work, and that makes
the Chairs and ADs get a buzz.

Reqarding industry doing defacto standards.  Yes this is happening now
with IPv6 Transition and several mechanisms are being deployed now that
are way ahead of the IETF.  That will correct itself between the market
and the IETF.  At times the market leads, but usually the IETF is in
synch with the curve, but not on time. But, v6ops is doing everything it
can to meet time-to-market and I for one applaud all of us here for that
we are getting real work done and on time.  As you know I am very pro
defacto standards and solutions when the IETF don't get it and a large
number of implementers do. We just move forward in industry and keep
sending data to this body called the IETF.  The IPv6 Forum is exactly
from the IETF moving to slow and in 1999 implementors took matters into
their own hands and now the IPv6 Forum is a world wide deployment body
that clearly can support defacto standards and with task forces that are
part of the IPv6 Forum across the planet.  That is what happens when any
standards body is to slow and does not meet the needs of the market.

I read every mail on this list and a few others and you have not been
treated unfairly at all, but your work has not reached consenus on this
list that I can see as working group items.  That does not mean it is
not good work but maybe not work in the IETF, as a question?  Ask your
self is it a protocol, operational tool that can be standard without
forcing implementation of protocols through configuration, a best
current practice, etc.?  And most important "what problem does your work
solve"? =20

What I have found with my work in the IETF when it stalls it is usually
there was no consensus on the problem it solves or there needs to first
be discussion of everyones assumptions.  For example, I believe many
customers will simply shut off IPv4 on a dual IPv4/IPv6 subnetwork and
cascade that policy expediently as a transition strategy across all
their other subnetworks until the entire customers Intranet or Internet
is IPv6 dominant with only pockets of legacy IPv4 for transition.
Educating all why and how is what I am doing now and once they see that
then solving the problem can move forward.  I also think most customers
now will go get IPv6 prefixes and 6to4 is highly questionable as widely
used for the transition and that is a new change in the market some of
us have learned directly.  These are just examples of others who have
the same problem and I don't think it is because of secret meetings in
the IETF.

I don't think the chairs or ADs warrant your mail and its unfair as one
working group members input these chairs work their ass off and do what
they can to keep things moving.  Now if they don't listen or ignore
consensus I will be the first to throw tomatoes, but I don't see that in
this specific case.

P.S. Pekka - I still do not agree with you about 70% of the time :--)

Regards,
/jim






From owner-v6ops@ops.ietf.org  Mon Nov  1 17:40:56 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14929
	for <v6ops-archive@lists.ietf.org>; Mon, 1 Nov 2004 17:40:56 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1COkp2-000ACO-Q7
	for v6ops-data@psg.com; Mon, 01 Nov 2004 22:38:44 +0000
Received: from [131.228.20.26] (helo=mgw-x3.nokia.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1COkp1-000AC9-CP
	for v6ops@ops.ietf.org; Mon, 01 Nov 2004 22:38:43 +0000
Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159])
	by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA1Mcel00018;
	Tue, 2 Nov 2004 00:38:40 +0200 (EET)
X-Scanned: Tue, 2 Nov 2004 00:36:33 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE
Received: (from root@localhost)
	by esdks004.ntc.nokia.com (8.12.9/8.12.9) id iA1MaX42013816;
	Tue, 2 Nov 2004 00:36:33 +0200
Received: from mgw-int1.ntc.nokia.com (172.21.143.96)
	by esdks004.ntc.nokia.com 00LEoxUS; Tue, 02 Nov 2004 00:36:31 EET
Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28])
	by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA1MaUa26655;
	Tue, 2 Nov 2004 00:36:30 +0200 (EET)
Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881);
	 Tue, 2 Nov 2004 00:36:31 +0200
Received: from esebe054.NOE.Nokia.com ([172.21.143.44]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881);
	 Tue, 2 Nov 2004 00:36:29 +0200
Received: ESEBE054.noe.nokia.com 172.21.143.44 from 10.162.252.179 10.162.252.179 via HTTP with MS-WebStorage 6.0.6249
Received: from localhost.localdomain by ESEBE054.noe.nokia.com; 02 Nov 2004 00:36:28 +0200
Subject: RE: WG process etc. [Re: WG last call on tunneling scenarios]
From: "Soininen Jonne (Nokia-NET/Helsinki)" <jonne.soininen@nokia.com>
To: "ext Bound, Jim" <jim.bound@hp.com>
Cc: jordi.palet@consulintel.es, v6ops@ops.ietf.org
In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B07A4D4B7@tayexc13.americas.cpqcorp.net>
References: 
	 <9C422444DE99BC46B3AD3C6EAFC9711B07A4D4B7@tayexc13.americas.cpqcorp.net>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1099348587.4605.56.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.6 
Date: Tue, 02 Nov 2004 00:36:28 +0200
X-OriginalArrivalTime: 01 Nov 2004 22:36:29.0216 (UTC) FILETIME=[3AB08A00:01C4C063]
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Ladies, and Gentlemen of the v6ops WG,

I understand that the slow process of our little WG causes some
frustration among the participants of the WG. 

Like you all know, we have had this scenarios/analysis project going on
for a long time. To facilitate the quickest possible ending of that
project we decided in the IETF#60 meeting to concentrate on finishing
just those tasks. This has practically meant that much of the work has
concentrated on the remaining analysis document, and the now three
requirements documents. 

Basically the plan was the following:

1) Finish the remaining analysis documents
2) Stabilize the requirements documents
3) Map the requirements to solutions
4) Refocus v6ops / start possibly needed work in the Internet Area

I think we are somewhere between steps 2 and 3, right?

I understand that people are anxious to start working on the actual
protocols - and believe me - I hope we could have started on the
technical work much earlier! However, sadly we just haven't gotten to
that point.

It is obvious that we have not communicated enough where are we going
and to some of you this has been an indication of us doing things behind
your backs. We'll try to behave better in the future. However, you
shouldn't worry at least Pekka and I plotting behind your backs - we
agree on so few things, it wouldn't be even possible! ;)

Cheers,

Jonne.

On Mon, 2004-11-01 at 22:28, ext Bound, Jim wrote:
> Jordi,
> 
> >On the other way around, I perfectly understand that industry is
> leading and some non-standards are 
> >becoming de facto standards, which is not good.
> >That's why we need to work faster and in parallel instead of in serial
> and slow mode. If the WG is not 
> >commenting or providing inputs, but there are no objections either, the
> work should be standardized.
> 
> This is your confusion and the IETF changed I think about 18 months ago
> or when we killed A6.  Specs cannot go forward from silence and that is
> now true in all IETF WGs I know of in the IETF.  I first ran into this
> in DHCPv6 working with Ralph as Chair many years ago.  I did not like it
> at first and did not get it.  Then we were able to get the engineers to
> comment on DHCPv6 and made the spec 10 times as strong and solid
> consensus.  So now I am a firm believer in silence is no good as metric
> to move a spec forward.  Zero conf work had lots of mail thread
> discussions and appears to be valid to accept as work item within the
> IETF.  Bottom line is the Chairs have not broken any rule but enforcing
> the rule.  Also sometimes the WG is just maxed.  For example we did not
> get input as fast as we needed it for Enterprise Analysis but then we go
> so much I am still parsing it as Ent Analysis editor.  I don't think
> there is any scientific method to this at all the longer I am around.  
> 
> There is also no secret discussions that is just absurd.  Is it possible
> the ADs and Chairs individually don't support specific work, sure, but
> that's another matter and their right, and fair too.  The objective is
> to get the WG excited technically about specific work, and that makes
> the Chairs and ADs get a buzz.
> 
> Reqarding industry doing defacto standards.  Yes this is happening now
> with IPv6 Transition and several mechanisms are being deployed now that
> are way ahead of the IETF.  That will correct itself between the market
> and the IETF.  At times the market leads, but usually the IETF is in
> synch with the curve, but not on time. But, v6ops is doing everything it
> can to meet time-to-market and I for one applaud all of us here for that
> we are getting real work done and on time.  As you know I am very pro
> defacto standards and solutions when the IETF don't get it and a large
> number of implementers do. We just move forward in industry and keep
> sending data to this body called the IETF.  The IPv6 Forum is exactly
> from the IETF moving to slow and in 1999 implementors took matters into
> their own hands and now the IPv6 Forum is a world wide deployment body
> that clearly can support defacto standards and with task forces that are
> part of the IPv6 Forum across the planet.  That is what happens when any
> standards body is to slow and does not meet the needs of the market.
> 
> I read every mail on this list and a few others and you have not been
> treated unfairly at all, but your work has not reached consenus on this
> list that I can see as working group items.  That does not mean it is
> not good work but maybe not work in the IETF, as a question?  Ask your
> self is it a protocol, operational tool that can be standard without
> forcing implementation of protocols through configuration, a best
> current practice, etc.?  And most important "what problem does your work
> solve"?  
> 
> What I have found with my work in the IETF when it stalls it is usually
> there was no consensus on the problem it solves or there needs to first
> be discussion of everyones assumptions.  For example, I believe many
> customers will simply shut off IPv4 on a dual IPv4/IPv6 subnetwork and
> cascade that policy expediently as a transition strategy across all
> their other subnetworks until the entire customers Intranet or Internet
> is IPv6 dominant with only pockets of legacy IPv4 for transition.
> Educating all why and how is what I am doing now and once they see that
> then solving the problem can move forward.  I also think most customers
> now will go get IPv6 prefixes and 6to4 is highly questionable as widely
> used for the transition and that is a new change in the market some of
> us have learned directly.  These are just examples of others who have
> the same problem and I don't think it is because of secret meetings in
> the IETF.
> 
> I don't think the chairs or ADs warrant your mail and its unfair as one
> working group members input these chairs work their ass off and do what
> they can to keep things moving.  Now if they don't listen or ignore
> consensus I will be the first to throw tomatoes, but I don't see that in
> this specific case.
> 
> P.S. Pekka - I still do not agree with you about 70% of the time :--)
> 
> Regards,
> /jim
> 
> 
-- 
Jonne Soininen
Nokia

Tel: +358 40 527 46 34
E-mail: jonne.soininen@nokia.com



From owner-v6ops@ops.ietf.org  Mon Nov  1 19:35:26 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26510
	for <v6ops-archive@lists.ietf.org>; Mon, 1 Nov 2004 19:35:25 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1COmcR-000OPE-K2
	for v6ops-data@psg.com; Tue, 02 Nov 2004 00:33:51 +0000
Received: from [213.172.48.142] (helo=consulintel.es)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1COmcQ-000OOt-2T
	for v6ops@ops.ietf.org; Tue, 02 Nov 2004 00:33:50 +0000
Received: from [10.10.10.102] ([217.126.187.160])
	by consulintel.es (consulintel.es [127.0.0.1])
	(MDaemon.PRO.v7.2.0.R)
	with ESMTP id md50000543526.msg
	for <v6ops@ops.ietf.org>; Tue, 02 Nov 2004 01:39:06 +0100
User-Agent: Microsoft-Entourage/10.1.4.030702.0
Date: Tue, 02 Nov 2004 01:21:15 +0100
Subject: Zero-Configuration Tunneling
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: <v6ops@ops.ietf.org>
Message-ID: <BDAC918B.4D2FB%jordi.palet@consulintel.es>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3182203969_1545105"
X-Spam-Processed: consulintel.es, Tue, 02 Nov 2004 01:39:06 +0100
	(not processed: message from valid local sender)
X-MDRemoteIP: 217.126.187.160
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ops.ietf.org
Reply-To: jordi.palet@consulintel.es
X-MDAV-Processed: consulintel.es, Tue, 02 Nov 2004 01:39:14 +0100
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE 
	autolearn=ham version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

>Este mensaje tiene formato MIME. Al no reconocer su lector de
correo este formato, puede que todo o parte del mensaje resulte ilegible.


--B_3182203969_1545105
Content-type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi all,

While working on
http://www.v6ops.euro6ix.net/ietf/draft-suryanarayanan-v6ops-zeroconf-reqs-0
1.txt

I=B9ve some disagreement with some of the co-authors.

The point was that in my opinion, the extensibility to support other
tunneling protocols is a must. For instance, in addition to support NAT
traversal, I will like to see in the solution also support for 4in6 and
6in6.

The question is, in your opinion this extensibility should be a =B3must=B2, a
=B3should=B2 or a =B3may=B2 ?

What is the opinion of the rest of the WG ?

Regards,
Jordi






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


--B_3182203969_1545105
Content-type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Zero-Configuration Tunneling</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Verdana"><SPAN STYLE=3D'font-size:12.0px'>Hi all,<BR>
<BR>
While working on<BR>
<a href=3D"http://www.v6ops.euro6ix.net/ietf/draft-suryanarayanan-v6ops-zeroconf-reqs-01.txt">http://www.v6ops.euro6ix.net/ietf/draft-suryanarayanan-v6ops-zeroconf-reqs-01.txt</a><BR>
<BR>
I&#8217;ve some disagreement with some of the co-authors.<BR>
<BR>
The point was that in my opinion, the extensibility to support other tunneling protocols is a must. For instance, in addition to support NAT traversal, I will like to see in the solution also support for 4in6 and 6in6.<BR>
<BR>
The question is, in your opinion this extensibility should be a &#8220;must&#8221;, a &#8220;should&#8221; or a &#8220;may&#8221; ?<BR>
<BR>
What is the opinion of the rest of the WG ?<BR>
<BR>
Regards,<BR>
Jordi<BR>
<BR>
<BR>
</SPAN></FONT>
<br><br>
**********************************<br>
Madrid 2003 Global IPv6 Summit<br>
Presentations and videos on line at:<br>
http://www.ipv6-es.com<br>
<br>
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.<br>
<br>
</body>
</HTML>


--B_3182203969_1545105--




From owner-v6ops@ops.ietf.org  Mon Nov  1 19:37:08 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26582
	for <v6ops-archive@lists.ietf.org>; Mon, 1 Nov 2004 19:37:08 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1COmfO-000OpK-1B
	for v6ops-data@psg.com; Tue, 02 Nov 2004 00:36:54 +0000
Received: from [213.172.48.142] (helo=consulintel.es)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1COmfM-000Ooy-Tf
	for v6ops@ops.ietf.org; Tue, 02 Nov 2004 00:36:53 +0000
Received: from [10.10.10.102] ([217.126.187.160])
	by consulintel.es (consulintel.es [127.0.0.1])
	(MDaemon.PRO.v7.2.0.R)
	with ESMTP id md50000543541.msg
	for <v6ops@ops.ietf.org>; Tue, 02 Nov 2004 01:42:04 +0100
User-Agent: Microsoft-Entourage/10.1.4.030702.0
Date: Tue, 02 Nov 2004 01:35:49 +0100
Subject: DHCP issue in draft-palet-v6ops-solution-tun-auto-disc-01.txt
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: <v6ops@ops.ietf.org>
Message-ID: <BDAC94F5.4D301%jordi.palet@consulintel.es>
In-Reply-To: <BDA1A8D4.4B856%jordi.palet@consulintel.es>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Spam-Processed: consulintel.es, Tue, 02 Nov 2004 01:42:04 +0100
	(not processed: message from valid local sender)
X-MDRemoteIP: 217.126.187.160
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ops.ietf.org
Reply-To: jordi.palet@consulintel.es
X-MDAV-Processed: consulintel.es, Tue, 02 Nov 2004 01:42:18 +0100
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi all,

Regarding draft-palet-v6ops-solution-tun-auto-disc-01.txt

There is an issue that had been discussed in my email on 24th Oct. with
Pekka.

Please, read the draft, and provide your inputs, specially on the need to
include a DHCP backup solution or not.

> My point of view is that both the ability to resolve SRV/A and anycast are
> already available today in all the clients, so making both as part of the
> requirement, will not add actually any new requirements.
> 
> I'm not considering DHCP at all. May be need to be further clarified. Is one
> more option, but more related, in my opinion, to very controlled networks
> where you are sure that DHCP options are relayed. We can even delete this
> section if it creates confusion. Thoughts from the WG well be needed here !
> 

Regards,
Jordi




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






From owner-v6ops@ops.ietf.org  Mon Nov  1 19:40:59 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26863
	for <v6ops-archive@lists.ietf.org>; Mon, 1 Nov 2004 19:40:58 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1COmiQ-000PKW-RC
	for v6ops-data@psg.com; Tue, 02 Nov 2004 00:40:02 +0000
Received: from [213.172.48.142] (helo=consulintel.es)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1COmiP-000PJX-JI
	for v6ops@ops.ietf.org; Tue, 02 Nov 2004 00:40:01 +0000
Received: from [10.10.10.102] ([217.126.187.160])
	by consulintel.es (consulintel.es [127.0.0.1])
	(MDaemon.PRO.v7.2.0.R)
	with ESMTP id md50000543547.msg
	for <v6ops@ops.ietf.org>; Tue, 02 Nov 2004 01:45:25 +0100
User-Agent: Microsoft-Entourage/10.1.4.030702.0
Date: Tue, 02 Nov 2004 01:39:09 +0100
Subject: Dual-faced DNS issue on
	draft-palet-v6ops-solution-tun-auto-disc-01.txt
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: <v6ops@ops.ietf.org>
Message-ID: <BDAC95BD.4D303%jordi.palet@consulintel.es>
In-Reply-To: <BDA1A8D4.4B856%jordi.palet@consulintel.es>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Spam-Processed: consulintel.es, Tue, 02 Nov 2004 01:45:25 +0100
	(not processed: message from valid local sender)
X-MDRemoteIP: 217.126.187.160
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ops.ietf.org
Reply-To: jordi.palet@consulintel.es
X-MDAV-Processed: consulintel.es, Tue, 02 Nov 2004 01:45:27 +0100
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi all,

Next issue with this document.

Please, read the document and provide inputs, specially on this point.

>>> Our intend here is to offer two options:
>>> 1) No service at all outside the ISP (then filtering will make it)
>>> 2) An ISP that offers services (some, may be not the same) to users outside
>>> its own network. I think this is a possibility and we must support it in a
>>> clear way, in case somebody want to make use of it.
>> 
>> I can understand these options, but AFAIK dual-faced DNS does not
>> offer any better means to achieve 2), while being a lot worse.  Sure,
>> you can hide the tunnel endpoint (so that it can only be looked up in
>> the local net) and still keep it operational if you move away from the
>> network, but that allows a lot of abuse (such as local customers
>> telling their friends outside the IP address to use for their
>> tunnels).  Doing dual-faced DNS here would be security by obscurity
>> and that would not be good.
>> 
>> The only practical solution to the 3rd party case appears to be some
>> form of registered mode, i.e., the tunnel endpoint being accessible to
>> anyone, but only allowing certain registered users.
> 
> I'm not really sure about this point of view. Need to think about it. More
> opinions from the WG, please ?
> 

Regards,
Jordi




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






From owner-v6ops@ops.ietf.org  Mon Nov  1 19:42:53 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26974
	for <v6ops-archive@lists.ietf.org>; Mon, 1 Nov 2004 19:42:53 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1COml1-000Pb3-CU
	for v6ops-data@psg.com; Tue, 02 Nov 2004 00:42:43 +0000
Received: from [213.172.48.142] (helo=consulintel.es)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1COml0-000Pan-6w
	for v6ops@ops.ietf.org; Tue, 02 Nov 2004 00:42:42 +0000
Received: from [10.10.10.102] ([217.126.187.160])
	by consulintel.es (consulintel.es [127.0.0.1])
	(MDaemon.PRO.v7.2.0.R)
	with ESMTP id md50000543552.msg
	for <v6ops@ops.ietf.org>; Tue, 02 Nov 2004 01:47:25 +0100
User-Agent: Microsoft-Entourage/10.1.4.030702.0
Date: Tue, 02 Nov 2004 01:41:21 +0100
Subject: A, CNAME or both issue on
	draft-palet-v6ops-solution-tun-auto-disc-01.txt
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: <v6ops@ops.ietf.org>
Message-ID: <BDAC9641.4D30C%jordi.palet@consulintel.es>
In-Reply-To: <BDA1A8D4.4B856%jordi.palet@consulintel.es>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Spam-Processed: consulintel.es, Tue, 02 Nov 2004 01:47:25 +0100
	(not processed: message from valid local sender)
X-MDRemoteIP: 217.126.187.160
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ops.ietf.org
Reply-To: jordi.palet@consulintel.es
X-MDAV-Processed: consulintel.es, Tue, 02 Nov 2004 01:48:07 +0100
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi all,

Last one ;-)

Please, once more, read the document and provide your inputs, specially on
this:


>>>> the client (rather the operating system)
>>>>  makes a DNS query [6][7] for QNAME=teredo_srv.ispname.com, QCLASS=IN,
>>>>  and QTYPE=A or QTYPE=CNAME.
>>>> 
>>>> ==> which QTYPE is it?  Are you saying the implementations need to query
>>>> both?  That's not good.  Note that if you do a QTYPE=A query, that should
>>>> also match CNAME and give the A record in the answer section, so there is
>>>> no
>>>> need to query CNAME explicitly.  Try e.g. 'dig aaaa ftp.ipv6.funet.fi'.
>>> 
>>> No, just query one of both, the one the OS prefers ;-)
>> 
>> Uhh, you need to specify better what to do so that it can be done in
>> an interoperable manner.  Or if you specify you have to query both,
>> that's OK too, but causes significant issues because it takes
>> additional packets and additional latency.
> 
> Yes, you're right. I guess it will be simple to stick to A, if we care so
> much about the extra packets. WG opinion ?


Regards,
Jordi




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






From owner-v6ops@ops.ietf.org  Mon Nov  1 20:05:38 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28184
	for <v6ops-archive@lists.ietf.org>; Mon, 1 Nov 2004 20:05:37 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1COn6j-0003CS-Ck
	for v6ops-data@psg.com; Tue, 02 Nov 2004 01:05:09 +0000
Received: from [213.172.48.142] (helo=consulintel.es)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1COn6h-0003Bl-Im
	for v6ops@ops.ietf.org; Tue, 02 Nov 2004 01:05:08 +0000
Received: from [10.10.10.102] ([217.126.187.160])
	by consulintel.es (consulintel.es [127.0.0.1])
	(MDaemon.PRO.v7.2.0.R)
	with ESMTP id md50000543562.msg
	for <v6ops@ops.ietf.org>; Tue, 02 Nov 2004 02:10:27 +0100
User-Agent: Microsoft-Entourage/10.1.4.030702.0
Date: Tue, 02 Nov 2004 02:04:53 +0100
Subject: Re: WG process etc. [Re: WG last call on tunneling scenarios]
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: <v6ops@ops.ietf.org>
Message-ID: <BDAC9BC5.4D34E%jordi.palet@consulintel.es>
In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B07A4D4B7@tayexc13.americas.cpqcorp.net>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Spam-Processed: consulintel.es, Tue, 02 Nov 2004 02:10:27 +0100
	(not processed: message from valid local sender)
X-MDRemoteIP: 217.126.187.160
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ops.ietf.org
Reply-To: jordi.palet@consulintel.es
X-MDAV-Processed: consulintel.es, Tue, 02 Nov 2004 02:10:33 +0100
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Jim,

See below, in-line.

Regards,
Jordi


> De: "Bound, Jim" <jim.bound@hp.com>
> Responder a: owner-v6ops@ops.ietf.org
> Fecha: Mon, 1 Nov 2004 15:28:18 -0500
> Para: <jordi.palet@consulintel.es>, <v6ops@ops.ietf.org>
> Asunto: RE: WG process etc. [Re: WG last call on tunneling scenarios]
> 
> Jordi,
> 
>> On the other way around, I perfectly understand that industry is
> leading and some non-standards are
>> becoming de facto standards, which is not good.
>> That's why we need to work faster and in parallel instead of in serial
> and slow mode. If the WG is not
>> commenting or providing inputs, but there are no objections either, the
> work should be standardized.
> 
> This is your confusion and the IETF changed I think about 18 months ago
> or when we killed A6.  Specs cannot go forward from silence and that is
> now true in all IETF WGs I know of in the IETF.  I first ran into this
> in DHCPv6 working with Ralph as Chair many years ago.  I did not like it
> at first and did not get it.  Then we were able to get the engineers to
> comment on DHCPv6 and made the spec 10 times as strong and solid
> consensus.  So now I am a firm believer in silence is no good as metric

This happened in this WG already, and is going to happen again with the last
calls send a couple of days ago.

In an ideal world, I will agree, that no WG comments is not good, but world
is not ideal, and even if a document is bad (or good), may be there are no
inputs. This is happening.

> to move a spec forward.  Zero conf work had lots of mail thread
> discussions and appears to be valid to accept as work item within the
> IETF.  Bottom line is the Chairs have not broken any rule but enforcing

Other documents also got lots of mail threads, and they aren't WG items.

And anyway, is difficult to measure if a document is or not a valid WG item
depending on the number of emails or threads, because it can be a simple
analysis which is clear, and not necessarily have comments. In our case, the
only comments that we got were from Brian mainly, regarding the missing SLP
analysis, which has been already done.


> the rule.  Also sometimes the WG is just maxed.  For example we did not
> get input as fast as we needed it for Enterprise Analysis but then we go
> so much I am still parsing it as Ent Analysis editor.  I don't think
> there is any scientific method to this at all the longer I am around.

My metric to see if a document is a valid WG item is the WG charter.
Otherwise, why we need the charter at all ?
And if the charter is not clear, then we should change it, but not start
discussing if this or that document is or not within the charter. You don't
think so ?

> 
> There is also no secret discussions that is just absurd.  Is it possible
> the ADs and Chairs individually don't support specific work, sure, but
> that's another matter and their right, and fair too.  The objective is
> to get the WG excited technically about specific work, and that makes
> the Chairs and ADs get a buzz.

Yes, you say it "individually" but that's not with their respective hats ...

Again the point is the charter is there for something.

> 
> Reqarding industry doing defacto standards.  Yes this is happening now
> with IPv6 Transition and several mechanisms are being deployed now that
> are way ahead of the IETF.  That will correct itself between the market
> and the IETF.  At times the market leads, but usually the IETF is in
> synch with the curve, but not on time. But, v6ops is doing everything it
> can to meet time-to-market and I for one applaud all of us here for that
> we are getting real work done and on time.  As you know I am very pro
> defacto standards and solutions when the IETF don't get it and a large
> number of implementers do. We just move forward in industry and keep
> sending data to this body called the IETF.  The IPv6 Forum is exactly
> from the IETF moving to slow and in 1999 implementors took matters into
> their own hands and now the IPv6 Forum is a world wide deployment body
> that clearly can support defacto standards and with task forces that are
> part of the IPv6 Forum across the planet.  That is what happens when any
> standards body is to slow and does not meet the needs of the market.
> 
> I read every mail on this list and a few others and you have not been
> treated unfairly at all, but your work has not reached consenus on this
> list that I can see as working group items.  That does not mean it is

Some of our works had been requested by the chairs, for example
tun-auto-disc, and we decided to take over it, because actually we already
were working on that direction.

Is not fair then that this should be WG item (specially because is an
analysis of an operational issue, which is part of the charter) ? Otherwise
is not fair that chairs ask for it ;-)

> not good work but maybe not work in the IETF, as a question?  Ask your
> self is it a protocol, operational tool that can be standard without
> forcing implementation of protocols through configuration, a best
> current practice, etc.?  And most important "what problem does your work
> solve"?  

All the answers to those questions bring me to the same conclusion ... It
should be a WG item, unless there is objection in the WG.

> 
> What I have found with my work in the IETF when it stalls it is usually
> there was no consensus on the problem it solves or there needs to first
> be discussion of everyones assumptions.  For example, I believe many
> customers will simply shut off IPv4 on a dual IPv4/IPv6 subnetwork and
> cascade that policy expediently as a transition strategy across all
> their other subnetworks until the entire customers Intranet or Internet
> is IPv6 dominant with only pockets of legacy IPv4 for transition.

Fully agree, you know, specially with only IPv6 ;-)

> Educating all why and how is what I am doing now and once they see that
> then solving the problem can move forward.  I also think most customers
> now will go get IPv6 prefixes and 6to4 is highly questionable as widely
> used for the transition and that is a new change in the market some of
> us have learned directly.  These are just examples of others who have
> the same problem and I don't think it is because of secret meetings in
> the IETF.
> 
> I don't think the chairs or ADs warrant your mail and its unfair as one
> working group members input these chairs work their ass off and do what
> they can to keep things moving.  Now if they don't listen or ignore
> consensus I will be the first to throw tomatoes, but I don't see that in
> this specific case.
> 
> P.S. Pekka - I still do not agree with you about 70% of the time :--)
> 
> Regards,
> /jim
> 
> 
> 
> 
> 



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






From owner-v6ops@ops.ietf.org  Mon Nov  1 20:08:50 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28492
	for <v6ops-archive@lists.ietf.org>; Mon, 1 Nov 2004 20:08:49 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1COnA8-0003h5-8I
	for v6ops-data@psg.com; Tue, 02 Nov 2004 01:08:40 +0000
Received: from [213.172.48.142] (helo=consulintel.es)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1COnA6-0003gV-Hb
	for v6ops@ops.ietf.org; Tue, 02 Nov 2004 01:08:39 +0000
Received: from [10.10.10.102] ([217.126.187.160])
	by consulintel.es (consulintel.es [127.0.0.1])
	(MDaemon.PRO.v7.2.0.R)
	with ESMTP id md50000543564.msg
	for <v6ops@ops.ietf.org>; Tue, 02 Nov 2004 02:13:48 +0100
User-Agent: Microsoft-Entourage/10.1.4.030702.0
Date: Tue, 02 Nov 2004 02:08:07 +0100
Subject: Re: WG process etc. [Re: WG last call on tunneling scenarios]
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: <v6ops@ops.ietf.org>
Message-ID: <BDAC9C87.4D34F%jordi.palet@consulintel.es>
In-Reply-To: <1099348587.4605.56.camel@localhost.localdomain>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Spam-Processed: consulintel.es, Tue, 02 Nov 2004 02:13:48 +0100
	(not processed: message from valid local sender)
X-MDRemoteIP: 217.126.187.160
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ops.ietf.org
Reply-To: jordi.palet@consulintel.es
X-MDAV-Processed: consulintel.es, Tue, 02 Nov 2004 02:14:04 +0100
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Jonne,

Well, as you know, I think this serial-mode has been wrong all the time. At
least a "pure-serial" mode.

I don't recall the WG being asked for doing this or not, just forced to.

Is that an open process ?

:-(

Regards,
Jordi


> De: "Soininen Jonne (Nokia-NET/Helsinki)" <jonne.soininen@nokia.com>
> Responder a: owner-v6ops@ops.ietf.org
> Fecha: Tue, 02 Nov 2004 00:36:28 +0200
> Para: "ext Bound, Jim" <jim.bound@hp.com>
> CC: jordi.palet@consulintel.es, v6ops@ops.ietf.org
> Asunto: RE: WG process etc. [Re: WG last call on tunneling scenarios]
> 
> Ladies, and Gentlemen of the v6ops WG,
> 
> I understand that the slow process of our little WG causes some
> frustration among the participants of the WG.
> 
> Like you all know, we have had this scenarios/analysis project going on
> for a long time. To facilitate the quickest possible ending of that
> project we decided in the IETF#60 meeting to concentrate on finishing
> just those tasks. This has practically meant that much of the work has
> concentrated on the remaining analysis document, and the now three
> requirements documents.
> 
> Basically the plan was the following:
> 
> 1) Finish the remaining analysis documents
> 2) Stabilize the requirements documents
> 3) Map the requirements to solutions
> 4) Refocus v6ops / start possibly needed work in the Internet Area
> 
> I think we are somewhere between steps 2 and 3, right?
> 
> I understand that people are anxious to start working on the actual
> protocols - and believe me - I hope we could have started on the
> technical work much earlier! However, sadly we just haven't gotten to
> that point.
> 
> It is obvious that we have not communicated enough where are we going
> and to some of you this has been an indication of us doing things behind
> your backs. We'll try to behave better in the future. However, you
> shouldn't worry at least Pekka and I plotting behind your backs - we
> agree on so few things, it wouldn't be even possible! ;)
> 
> Cheers,
> 
> Jonne.
> 
> On Mon, 2004-11-01 at 22:28, ext Bound, Jim wrote:
>> Jordi,
>> 
>>> On the other way around, I perfectly understand that industry is
>> leading and some non-standards are
>>> becoming de facto standards, which is not good.
>>> That's why we need to work faster and in parallel instead of in serial
>> and slow mode. If the WG is not
>>> commenting or providing inputs, but there are no objections either, the
>> work should be standardized.
>> 
>> This is your confusion and the IETF changed I think about 18 months ago
>> or when we killed A6.  Specs cannot go forward from silence and that is
>> now true in all IETF WGs I know of in the IETF.  I first ran into this
>> in DHCPv6 working with Ralph as Chair many years ago.  I did not like it
>> at first and did not get it.  Then we were able to get the engineers to
>> comment on DHCPv6 and made the spec 10 times as strong and solid
>> consensus.  So now I am a firm believer in silence is no good as metric
>> to move a spec forward.  Zero conf work had lots of mail thread
>> discussions and appears to be valid to accept as work item within the
>> IETF.  Bottom line is the Chairs have not broken any rule but enforcing
>> the rule.  Also sometimes the WG is just maxed.  For example we did not
>> get input as fast as we needed it for Enterprise Analysis but then we go
>> so much I am still parsing it as Ent Analysis editor.  I don't think
>> there is any scientific method to this at all the longer I am around.
>> 
>> There is also no secret discussions that is just absurd.  Is it possible
>> the ADs and Chairs individually don't support specific work, sure, but
>> that's another matter and their right, and fair too.  The objective is
>> to get the WG excited technically about specific work, and that makes
>> the Chairs and ADs get a buzz.
>> 
>> Reqarding industry doing defacto standards.  Yes this is happening now
>> with IPv6 Transition and several mechanisms are being deployed now that
>> are way ahead of the IETF.  That will correct itself between the market
>> and the IETF.  At times the market leads, but usually the IETF is in
>> synch with the curve, but not on time. But, v6ops is doing everything it
>> can to meet time-to-market and I for one applaud all of us here for that
>> we are getting real work done and on time.  As you know I am very pro
>> defacto standards and solutions when the IETF don't get it and a large
>> number of implementers do. We just move forward in industry and keep
>> sending data to this body called the IETF.  The IPv6 Forum is exactly
>> from the IETF moving to slow and in 1999 implementors took matters into
>> their own hands and now the IPv6 Forum is a world wide deployment body
>> that clearly can support defacto standards and with task forces that are
>> part of the IPv6 Forum across the planet.  That is what happens when any
>> standards body is to slow and does not meet the needs of the market.
>> 
>> I read every mail on this list and a few others and you have not been
>> treated unfairly at all, but your work has not reached consenus on this
>> list that I can see as working group items.  That does not mean it is
>> not good work but maybe not work in the IETF, as a question?  Ask your
>> self is it a protocol, operational tool that can be standard without
>> forcing implementation of protocols through configuration, a best
>> current practice, etc.?  And most important "what problem does your work
>> solve"?  
>> 
>> What I have found with my work in the IETF when it stalls it is usually
>> there was no consensus on the problem it solves or there needs to first
>> be discussion of everyones assumptions.  For example, I believe many
>> customers will simply shut off IPv4 on a dual IPv4/IPv6 subnetwork and
>> cascade that policy expediently as a transition strategy across all
>> their other subnetworks until the entire customers Intranet or Internet
>> is IPv6 dominant with only pockets of legacy IPv4 for transition.
>> Educating all why and how is what I am doing now and once they see that
>> then solving the problem can move forward.  I also think most customers
>> now will go get IPv6 prefixes and 6to4 is highly questionable as widely
>> used for the transition and that is a new change in the market some of
>> us have learned directly.  These are just examples of others who have
>> the same problem and I don't think it is because of secret meetings in
>> the IETF.
>> 
>> I don't think the chairs or ADs warrant your mail and its unfair as one
>> working group members input these chairs work their ass off and do what
>> they can to keep things moving.  Now if they don't listen or ignore
>> consensus I will be the first to throw tomatoes, but I don't see that in
>> this specific case.
>> 
>> P.S. Pekka - I still do not agree with you about 70% of the time :--)
>> 
>> Regards,
>> /jim
>> 
>> 
> -- 
> Jonne Soininen
> Nokia
> 
> Tel: +358 40 527 46 34
> E-mail: jonne.soininen@nokia.com
> 
> 



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






From owner-v6ops@ops.ietf.org  Mon Nov  1 20:12:28 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28770
	for <v6ops-archive@lists.ietf.org>; Mon, 1 Nov 2004 20:12:28 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1COnDY-0004FM-H2
	for v6ops-data@psg.com; Tue, 02 Nov 2004 01:12:12 +0000
Received: from [203.254.224.25] (helo=mailout2.samsung.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1COnDX-0004F7-HN
	for v6ops@ops.ietf.org; Tue, 02 Nov 2004 01:12:11 +0000
Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com
 (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003))
 id <0I6J00636209AU@mailout2.samsung.com> for v6ops@ops.ietf.org; Tue,
 02 Nov 2004 10:12:10 +0900 (KST)
Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25])
 by mailout2.samsung.com
 (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003))
 with ESMTP id <0I6J0002S1XP8X@mailout2.samsung.com> for v6ops@ops.ietf.org;
 Tue, 02 Nov 2004 10:10:37 +0900 (KST)
Received: from LocalHost ([168.219.198.109])
 by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004))
 with ESMTPA id <0I6J007AL1XOQN@mmp1.samsung.com> for v6ops@ops.ietf.org; Tue,
 02 Nov 2004 10:10:37 +0900 (KST)
Date: Tue, 02 Nov 2004 10:12:09 +0900
From: Soohong Daniel Park <soohong.park@samsung.com>
Subject: RE: DHCP issue in draft-palet-v6ops-solution-tun-auto-disc-01.txt
In-reply-to: <BDAC94F5.4D301%jordi.palet@consulintel.es>
To: v6ops@ops.ietf.org, jordi.palet@consulintel.es
Cc: Dhcwg <dhcwg@ietf.org>
Message-id: <EDELKJDGPGNIPOAOHMNPIEAFGJAA.soohong.park@samsung.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7BIT

>I'm not considering DHCP at all. May be need to be further 
>clarified. Is one more option, but more related, in my opinion, 
>to very controlled networks where you are sure that DHCP 
>options are relayed. We can even delete this section if it 
>creates confusion. 

*controlled networks* is also important domain for adopting
IPv6 widely, especially enterprise network is entirely controlled
by network administrator. Also enabling DHCP is quite normal,
cheap and a widely deployed scenario. This solution works
very well within our enterprise network.

>Thoughts from the WG well be needed here !

Which WG do you mean ? DHC WG or V6OPS WG or both ?


     Daniel (Soohong Daniel Park)
     Mobile Platform Lab. Samsung Electronics.




From owner-v6ops@ops.ietf.org  Mon Nov  1 20:12:44 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28790
	for <v6ops-archive@lists.ietf.org>; Mon, 1 Nov 2004 20:12:44 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1COnE0-0004JP-GD
	for v6ops-data@psg.com; Tue, 02 Nov 2004 01:12:40 +0000
Received: from [213.172.48.142] (helo=consulintel.es)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1COnDz-0004Iw-82
	for v6ops@ops.ietf.org; Tue, 02 Nov 2004 01:12:39 +0000
Received: from [10.10.10.102] ([217.126.187.160])
	by consulintel.es (consulintel.es [127.0.0.1])
	(MDaemon.PRO.v7.2.0.R)
	with ESMTP id md50000543573.msg
	for <v6ops@ops.ietf.org>; Tue, 02 Nov 2004 02:18:00 +0100
User-Agent: Microsoft-Entourage/10.1.4.030702.0
Date: Tue, 02 Nov 2004 02:12:26 +0100
Subject: draft-palet-v6ops-tun-auto-disc-02.txt
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: <v6ops@ops.ietf.org>
Message-ID: <BDAC9D8A.4D35B%jordi.palet@consulintel.es>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3182206346_1650287"
X-Spam-Processed: consulintel.es, Tue, 02 Nov 2004 02:18:00 +0100
	(not processed: message from valid local sender)
X-MDRemoteIP: 217.126.187.160
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ops.ietf.org
Reply-To: jordi.palet@consulintel.es
X-MDAV-Processed: consulintel.es, Tue, 02 Nov 2004 02:18:04 +0100
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE 
	autolearn=ham version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

>Este mensaje tiene formato MIME. Al no reconocer su lector de
correo este formato, puede que todo o parte del mensaje resulte ilegible.


--B_3182206346_1650287
Content-type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Hi all,

Just a note on my previous emails. The right version of this document is
-02, available at:

ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-palet-v6ops-tun-auto
-disc-02.txt

Please, read this document and provide your comments !

Thanks in advance for that.

Regards,
Jordi





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


--B_3182206346_1650287
Content-type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>draft-palet-v6ops-tun-auto-disc-02.txt</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Verdana"><SPAN STYLE=3D'font-size:12.0px'>Hi all,<BR>
<BR>
Just a note on my previous emails. The right version of this document is -02, available at:<BR>
<BR>
<a href=3D"ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-palet-v6ops-tun-auto-disc-02.txt">ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-palet-v6ops-tun-auto-disc-02.txt</a><BR>
<BR>
Please, read this document and provide your comments !<BR>
<BR>
Thanks in advance for that.<BR>
<BR>
Regards,<BR>
Jordi<BR>
<BR>
</SPAN></FONT>
<br><br>
**********************************<br>
Madrid 2003 Global IPv6 Summit<br>
Presentations and videos on line at:<br>
http://www.ipv6-es.com<br>
<br>
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.<br>
<br>
</body>
</HTML>


--B_3182206346_1650287--




From owner-v6ops@ops.ietf.org  Mon Nov  1 20:19:02 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29293
	for <v6ops-archive@lists.ietf.org>; Mon, 1 Nov 2004 20:19:02 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1COnJr-0005Dq-B7
	for v6ops-data@psg.com; Tue, 02 Nov 2004 01:18:43 +0000
Received: from [213.172.48.142] (helo=consulintel.es)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1COnJq-0005DX-4Z
	for v6ops@ops.ietf.org; Tue, 02 Nov 2004 01:18:42 +0000
Received: from [10.10.10.102] ([217.126.187.160])
	by consulintel.es (consulintel.es [127.0.0.1])
	(MDaemon.PRO.v7.2.0.R)
	with ESMTP id md50000543578.msg
	for <v6ops@ops.ietf.org>; Tue, 02 Nov 2004 02:24:03 +0100
User-Agent: Microsoft-Entourage/10.1.4.030702.0
Date: Tue, 02 Nov 2004 02:17:06 +0100
Subject: Latest version of Tunnel end-point auto-discovery analysis and
	solution
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: <v6ops@ops.ietf.org>
Message-ID: <BDAC9EA2.4D35D%jordi.palet@consulintel.es>
Mime-version: 1.0
X-Priority: 1
Content-type: multipart/alternative; boundary="B_3182206627_1705753"
X-Spam-Processed: consulintel.es, Tue, 02 Nov 2004 02:24:03 +0100
	(not processed: message from valid local sender)
X-MDRemoteIP: 217.126.187.160
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ops.ietf.org
Reply-To: jordi.palet@consulintel.es
X-MDAV-Processed: consulintel.es, Tue, 02 Nov 2004 02:24:07 +0100
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-3.6 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE,
	PRIORITY_NO_NAME,X_PRIORITY_HIGH autolearn=no version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

>Este mensaje tiene formato MIME. Al no reconocer su lector de
correo este formato, puede que todo o parte del mensaje resulte ilegible.


--B_3182206627_1705753
Content-type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Hi all,

Recently we had submitted new versions for the IPv6 Tunnel End-Point
Auto-Discovery analysis and solution.

We have not received further comments on those documents.

Once more I will like to make sure that you're aware of this, so here are
the links to both documents:

ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-palet-v6ops-tun-auto
-disc-02.txt
ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-palet-v6ops-solution
-tun-auto-disc-01.txt

Please, provide your comments !

Regards,
Jordi





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


--B_3182206627_1705753
Content-type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Latest version of Tunnel end-point auto-discovery analysis and solution</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Verdana"><SPAN STYLE=3D'font-size:12.0px'>Hi all,<BR>
<BR>
Recently we had submitted new versions for the IPv6 Tunnel End-Point Auto-Discovery analysis and solution.<BR>
<BR>
We have not received further comments on those documents.<BR>
<BR>
Once more I will like to make sure that you're aware of this, so here are the links to both documents:<BR>
<BR>
<a href=3D"ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-palet-v6ops-tun-auto-disc-02.txt">ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-palet-v6ops-tun-auto-disc-02.txt</a><BR>
<a href=3D"ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-palet-v6ops-solution-tun-auto-disc-01.txt">ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-palet-v6ops-solution-tun-auto-disc-01.txt</a><BR>
<BR>
Please, provide your comments !<BR>
<BR>
Regards,<BR>
Jordi<BR>
<BR>
</SPAN></FONT>
<br><br>
**********************************<br>
Madrid 2003 Global IPv6 Summit<br>
Presentations and videos on line at:<br>
http://www.ipv6-es.com<br>
<br>
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.<br>
<br>
</body>
</HTML>


--B_3182206627_1705753--




From owner-v6ops@ops.ietf.org  Mon Nov  1 20:27:16 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29960
	for <v6ops-archive@lists.ietf.org>; Mon, 1 Nov 2004 20:27:15 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1COnRt-0006Qo-PA
	for v6ops-data@psg.com; Tue, 02 Nov 2004 01:27:01 +0000
Received: from [213.172.48.142] (helo=consulintel.es)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1COnRs-0006QO-Hp
	for v6ops@ops.ietf.org; Tue, 02 Nov 2004 01:27:00 +0000
Received: from [10.10.10.102] ([217.126.187.160])
	by consulintel.es (consulintel.es [127.0.0.1])
	(MDaemon.PRO.v7.2.0.R)
	with ESMTP id md50000543586.msg
	for <v6ops@ops.ietf.org>; Tue, 02 Nov 2004 02:32:23 +0100
User-Agent: Microsoft-Entourage/10.1.4.030702.0
Date: Tue, 02 Nov 2004 02:26:46 +0100
Subject: Re: DHCP issue in draft-palet-v6ops-solution-tun-auto-disc-01.txt
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: <v6ops@ops.ietf.org>
CC: <dhcwg@ietf.org>
Message-ID: <BDACA0E6.4D372%jordi.palet@consulintel.es>
In-Reply-To: <EDELKJDGPGNIPOAOHMNPIEAFGJAA.soohong.park@samsung.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Spam-Processed: consulintel.es, Tue, 02 Nov 2004 02:32:23 +0100
	(not processed: message from valid local sender)
X-MDRemoteIP: 217.126.187.160
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ops.ietf.org
Reply-To: jordi.palet@consulintel.es
X-MDAV-Processed: consulintel.es, Tue, 02 Nov 2004 02:32:26 +0100
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Daniel,

My original email was in v6ops, because I think is that WG who should decide
about if the document (draft-palet-v6ops-solution-tun-auto-disc-01.txt) need
to keep or not the DHCP solution for "controlled networks".

I agree with your comment, let's see what the rest of the WG say.

Regards,
Jordi

> De: Soohong Daniel Park <soohong.park@samsung.com>
> Responder a: owner-v6ops@ops.ietf.org
> Fecha: Tue, 02 Nov 2004 10:12:09 +0900
> Para: v6ops@ops.ietf.org, jordi.palet@consulintel.es
> CC: Dhcwg <dhcwg@ietf.org>
> Asunto: RE: DHCP issue in draft-palet-v6ops-solution-tun-auto-disc-01.txt
> 
>> I'm not considering DHCP at all. May be need to be further
>> clarified. Is one more option, but more related, in my opinion,
>> to very controlled networks where you are sure that DHCP
>> options are relayed. We can even delete this section if it
>> creates confusion.
> 
> *controlled networks* is also important domain for adopting
> IPv6 widely, especially enterprise network is entirely controlled
> by network administrator. Also enabling DHCP is quite normal,
> cheap and a widely deployed scenario. This solution works
> very well within our enterprise network.
> 
>> Thoughts from the WG well be needed here !
> 
> Which WG do you mean ? DHC WG or V6OPS WG or both ?
> 
> 
>    Daniel (Soohong Daniel Park)
>    Mobile Platform Lab. Samsung Electronics.
> 
> 
> 



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






From owner-v6ops@ops.ietf.org  Mon Nov  1 22:17:37 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16019
	for <v6ops-archive@lists.ietf.org>; Mon, 1 Nov 2004 22:17:36 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1COp8i-000JI3-TB
	for v6ops-data@psg.com; Tue, 02 Nov 2004 03:15:20 +0000
Received: from [203.253.3.140] (helo=cns.ssu.ac.kr)
	by psg.com with smtp (Exim 4.41 (FreeBSD))
	id 1COp8h-000JHN-Lk
	for v6ops@ops.ietf.org; Tue, 02 Nov 2004 03:15:20 +0000
Received: from cnsljjang (203.253.3.137)
	by cns.ssu.ac.kr (203.253.3.140) with [Nmail V3.2 20020608(S)]
	for <v6ops@ops.ietf.org> from <ischl@cns.ssu.ac.kr>;
	Tue, 02 Nov 2004 12:21:29 +0900
From: =?ks_c_5601-1987?B?w9bAzryu?= <ischl@cns.ssu.ac.kr>
To: <v6ops@ops.ietf.org>
Subject: RE: IPsec support for NAT-PT in IPv6 
Date: Tue, 2 Nov 2004 12:15:20 +0900
MIME-Version: 1.0
Content-Type: text/plain;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Thread-Index: AcS9tdHP0fZF8Sl4QYyUEVT/fiUv2QABnKyAALN52YA=
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-3.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Message-Id: <E1COp8i-000JI3-TB@psg.com>
Content-Transfer-Encoding: quoted-printable



-----Original Message-----
From: =C3=D6=C0=CE=BC=AE [mailto:ischl@cns.ssu.ac.kr]=20
Sent: Friday, October 29, 2004 11:30 PM
To: 'Francis.Dupont@enst-bretagne.fr'
Subject: RE: IPsec support for NAT-PT in IPv6=20



-----Original Message-----
From: Francis.Dupont@enst-bretagne.fr [mailto:Francis.Dupont@enst-
bretagne.fr]=20
Sent: Friday, October 29, 2004 9:44 PM
To: =C3=D6=C0=CE=BC=AE
Cc: v6ops@ops.ietf.org
Subject: Re: IPsec support for NAT-PT in IPv6=20

 In your previous mail you wrote:

   Comments welcome.
  =20
=3D> in section 2.1:
   The IP addresses are usually used as the ID values in this procedure.

 this is not true: draft-ietf-pki4ipsec-ikecert-profile-03.txt:
   ... Of these types, FQDN and USER_FQDN are
   RECOMMENDED over IP addresses (see discussion in Section 3.1.1).

   and in section 3.1.1 there is the rationale:

   Implementations SHOULD NOT populate ID payload with IP addresses due
   to interoperability issues such as problems with NAT traversal, and
   problems with IP verification behavior.

 So the solution is simple: avoid (put a MUST NOT) ID payload with
 IP addresses as it is already done for the NAT traversal.

=3D> section 2.2 describes a NAT problem, not a NAT-PT problem.
I don't understand why section 3 doesn't try to extend the NAT traversal
mechanism...

=3D> section 4 doesn't make sense : IKE already works well through a =
NAT.

=3D> idem for section 5. If the only issue is the transport checksum
the current NAT traversal has NAT-OA payloads to fix it.

So my recommendation is to refer to RFC 3715 (IPsec-Network Address
Translation (NAT) Compatibility Requirements) and its companion solution
I-D draft-ietf-ipsec-nat-t-ike-08.txt

Regards

Francis.Dupont@enst-bretagne.fr

-------------------------------------------------------------------------=
---
Thanks for your comment
Basically NAT-PT is likely NAT, but you give consideration to =
translation
from IPv6 to IPv4 or from IPv4 to IPv6.
 =20
In 2.1 =3D=3D> Only if IKE procedure uses FQDN and USER_FQDN, you are =
correct.
But I think FQDN and USER_FQDM is not usually use in real application.

In 2.2 =3D=3D> It is NAT-PT problem which ICV calculate problem.
             NAT-PT node calculate with IPv6 header and Payload, however
IPv4
             node verify IPv4 header and Payload.

In 4 =3D=3D> IKE doesn't work well through a NAT, because it has =
firewall issue.
           Therefore Solution was offered IPsec-Tunnel mode and RSIP in =
NAT.
In 5 =3D=3D> IPsec AH mode problem is ICV calculation using IP header =
but not
transport checksum.




From owner-v6ops@ops.ietf.org  Mon Nov  1 23:55:49 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25001
	for <v6ops-archive@lists.ietf.org>; Mon, 1 Nov 2004 23:55:49 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1COqgS-0003Xw-4B
	for v6ops-data@psg.com; Tue, 02 Nov 2004 04:54:16 +0000
Received: from [64.233.184.207] (helo=wproxy.gmail.com)
 	by psg.com with esmtp (Exim 4.41 (FreeBSD))
 	id 1COkvU-000AuK-VH
 	for v6ops@ops.ietf.org; Mon, 01 Nov 2004 22:45:25 +0000
Received: by wproxy.gmail.com with SMTP id 45so148775wri
         for <v6ops@ops.ietf.org>; Mon, 01 Nov 2004 14:45:23 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
         s=beta; d=gmail.com;
         h=received:message-id:date:from:reply-to:to:subject:cc:mime-version:content-type:content-transfer-encoding;
         b=centWjz399YNCHvTCq1CPQAA9r9txZdLpqPEEbgMQhE+bdiU/+845h0Pr/aOIecalUxItCxbsEyHoIuzcJGWeMnQ35jhbx+dpeBJCBPJzPr56kPGM8Ot7145Xv+drxsYtXPwb2tqekuPw97zV+RKO1U+aZ7QZR2nXJd4cTDg+DU=
Received: by 10.54.27.11 with SMTP id a11mr163790wra;
         Mon, 01 Nov 2004 14:45:23 -0800 (PST)
Received: by 10.54.27.75 with HTTP; Mon, 1 Nov 2004 14:45:23 -0800 (PST)
Message-ID: <1774621e041101144514ded4b5@mail.gmail.com>
Date: Mon, 1 Nov 2004 22:45:23 +0000
From: the otter <2the.otter@gmail.com>
Reply-To: the otter <2the.otter@gmail.com>
To: karen.e.neilsen@ericsson.com
Subject: draft-nielsen-v6ops-3GPP-zeroconf-goals-00.txt
Cc: v6ops@ops.ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham
 	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Karen,
Regarding the draft draft-nielsen-v6ops-3GPP-zeroconf-goals-00.txt, I
would like to ask about push functionality and user identity within
the 3GPP network.
PUSH relates to tunnel duration/accessibility:

>6.7. Tunnel Link Sustainability
>
>  The tunnel link established in between a host deploying Zero-
>  Configuration Tunneling and an associated Tunnel Server should be
>  expected to remain in administrative active state for the lifetime of
>  the IPv6 address provided to the host.
>
>  The tunnel protocol must not mandate keep-alive messages to be
>  transmitted by the host simply in order to sustain tunnel link
>  connectivity.

Is it intended that the tunnel remain up while the UE has an active
PDP context?
In an "always-on" network there may be services that perform PUSH
(i.e. server initiated) functions - is it a requirement to allow IP PUSH from
the IPv6 domain toward the client?
I would suggest that this be a requirement or it will limit the
service use cases for this solution.
The PUSH functionality leads on to the User Identity issue which
relates mainly to this section:

>6.6. Address Assignment
>
>  The tunnel protocol must allow for the assignment of at least one
>  globally routable (/128) IPv6 unicast address to use for tunneled
>  IPv6 connectivity over the link provided by the Zero-Configuration
>  Tunneling mechanism.

3GPP networks may utilise a database that combines authentication and
DHCP functions (RADIUS + database). This ensures there is an
authoritative system that can provide "User Identity", that is to say link
IP address to User Account. A service can then query the data base to
resolve an IP address to a User account or vice versa. Is the IPv6
address assignment for the tunnel client compatible with this model?
If this is not provided then some types of services in the IPv6 domain
will not work. May I suggest that maintaining user ID mapping via IP
address be a goal.
If these are not to be goals then perhaps this could be stated.

IMHO the issue I see with leaving these out is the transition mechanism
becomes a solution for only the most basic of "web" type services.
While this makes the solution simple, it removes the motivation for
IPv6 within the 3GPP network. It is important to at least match or
mimic the functionality available in the IPv4 domain.

Best Regards,
N



From owner-v6ops@ops.ietf.org  Tue Nov  2 00:54:26 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29375
	for <v6ops-archive@lists.ietf.org>; Tue, 2 Nov 2004 00:54:26 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1COrbs-0009Ll-Dw
	for v6ops-data@psg.com; Tue, 02 Nov 2004 05:53:36 +0000
Received: from [131.228.20.21] (helo=mgw-x1.nokia.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1COrbr-0009LN-3j
	for v6ops@ops.ietf.org; Tue, 02 Nov 2004 05:53:35 +0000
Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121])
	by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA25rX304524;
	Tue, 2 Nov 2004 07:53:33 +0200 (EET)
X-Scanned: Tue, 2 Nov 2004 07:50:55 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE
Received: (from root@localhost)
	by esdks002.ntc.nokia.com (8.12.9/8.12.9) id iA25otEc002481;
	Tue, 2 Nov 2004 07:50:55 +0200
Received: from mgw-int2.ntc.nokia.com (172.21.143.97)
	by esdks002.ntc.nokia.com 001C3SQt; Tue, 02 Nov 2004 07:50:54 EET
Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121])
	by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA25orS03364;
	Tue, 2 Nov 2004 07:50:53 +0200 (EET)
Received: from dadhcp-172019068136.americas.nokia.com ([172.19.68.140]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881);
	 Mon, 1 Nov 2004 23:50:52 -0600
Received: from dadhcp-172019068136.americas.nokia.com (localhost.localdomain [127.0.0.1])
	by dadhcp-172019068136.americas.nokia.com (8.12.8/8.12.8) with ESMTP id iA25op1H024203;
	Mon, 1 Nov 2004 21:50:51 -0800
Received: (from kessens@localhost)
	by dadhcp-172019068136.americas.nokia.com (8.12.8/8.12.8/Submit) id iA25oopl024201;
	Mon, 1 Nov 2004 21:50:50 -0800
Date: Mon, 1 Nov 2004 21:50:50 -0800
From: David Kessens <david.kessens@nokia.com>
To: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
Cc: v6ops@ops.ietf.org
Subject: Re: WG last call on tunneling scenarios
Message-ID: <20041102055050.GA23685@nokia.com>
References: <Pine.LNX.4.61.0410291149220.9900@netcore.fi> <BDAAF64C.4D0BA%jordi.palet@consulintel.es>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <BDAAF64C.4D0BA%jordi.palet@consulintel.es>
User-Agent: Mutt/1.4.1i
X-OriginalArrivalTime: 02 Nov 2004 05:50:52.0225 (UTC) FILETIME=[E9741B10:01C4C09F]
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk


Jordi,

On Sun, Oct 31, 2004 at 08:06:36PM +0100, JORDI PALET MARTINEZ wrote:
> 
> Let me explain. In general I feel that there is too much secret discussions
> among the ADs and the co-chairs. I never understood why this talks doesn't
> happen within the WG mail exploder, to get other inputs, ideas, or whatever
> from the WG. Even if you only get a couple of them, they might be useful.

This is from far the truth and you know that. The things that we
discuss privately are mostly about procedural issues and follow up on
documents that are in IESG review.

The only topic outside this category that we recently talked about is
the future of the working group. I already mentioned at last IETF
meeting that this a topic is soon going to be important for the simple
reason that most work items are now close to completion. Normally, in
the life of an IETF working group, that is a good time to start
thinking about what is next. Note that the discussions that we had
were *not* to make decisions, they were intended to explore the
various options that exist.

In order to discuss this further in all openness we asked the chairs
to allocate some time on the agenda to talk about this:

---
Discussion of the way forward - 15 mins, Chairs/ADs
 - GOAL: discuss and get consensus on how to proceed from here
---

(and yes, I think we could possibly use a bit more than 15 minutes :-))

> So, I absolutely disagree with the way the decisions are being taken. This
> is not consensus, is probably something closer to a semi-dictatorial
> process, and don't take me wrong, you know that I don't have anything
> personally against anyone, ADs and co-chairs included, but I prefer much
> more being honest, open and clear. 

This paragraph is very close to accusing the ADs and the co-chairs of
dishonesty. I hope you tried to say something different :-). 
 
David Kessens
---



From owner-v6ops@ops.ietf.org  Tue Nov  2 01:18:14 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01647
	for <v6ops-archive@lists.ietf.org>; Tue, 2 Nov 2004 01:18:13 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1COryK-000CPt-0x
	for v6ops-data@psg.com; Tue, 02 Nov 2004 06:16:48 +0000
Received: from [203.253.3.140] (helo=cns.ssu.ac.kr)
	by psg.com with smtp (Exim 4.41 (FreeBSD))
	id 1COryI-000CPP-Dt
	for v6ops@ops.ietf.org; Tue, 02 Nov 2004 06:16:46 +0000
Received: from cnsljjang (203.253.3.137)
	by cns.ssu.ac.kr (203.253.3.140) with [Nmail V3.2 20020608(S)]
	for <v6ops@ops.ietf.org> from <ischl@cns.ssu.ac.kr>;
	Tue, 02 Nov 2004 15:22:52 +0900
From: "Inseok Choi" <ischl@cns.ssu.ac.kr>
To: "'Francis Dupont'" <Francis.Dupont@enst-bretagne.fr>
Cc: <v6ops@ops.ietf.org>
Subject: RE: IPsec support for NAT-PT in IPv6 
Date: Tue, 2 Nov 2004 15:16:44 +0900
MIME-Version: 1.0
Content-Type: text/plain;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-Reply-To: <200410291243.i9TChmSj037070@givry.rennes.enst-bretagne.fr>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Thread-Index: AcS9ueMaq3BtGzTVTtmSBZoXV+D9BAC59O8Q
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-3.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Message-Id: <E1COryK-000CPt-0x@psg.com>
Content-Transfer-Encoding: quoted-printable

in 2.1 =3D=3D> My proposed mechanism was assume IKE using preshared key =
Phase.
If we can't IKE using use certificate, we should use IKE using other =
way.

in IPsec using UDP encapsulation =3D=3D> NAT-PT can't apply to it. If we =
use
IPsec using UDP encapsulation in NAT-PT, NAT-PT server may send IPv4-in-
IPv6 packet. However IPv4 node don't understand IPv6 packet.

Therefore, NAT traversal method can be applied to NAT-PT mechanism.

-----Original Message-----
From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On =
Behalf
Of Francis Dupont
Sent: Friday, October 29, 2004 9:44 PM
To: =C3=D6=C0=CE=BC=AE
Cc: v6ops@ops.ietf.org
Subject: Re: IPsec support for NAT-PT in IPv6=20

 In your previous mail you wrote:

   Comments welcome.
  =20
=3D> in section 2.1:
   The IP addresses are usually used as the ID values in this procedure.

 this is not true: draft-ietf-pki4ipsec-ikecert-profile-03.txt:
   ... Of these types, FQDN and USER_FQDN are
   RECOMMENDED over IP addresses (see discussion in Section 3.1.1).

   and in section 3.1.1 there is the rationale:

   Implementations SHOULD NOT populate ID payload with IP addresses due
   to interoperability issues such as problems with NAT traversal, and
   problems with IP verification behavior.

 So the solution is simple: avoid (put a MUST NOT) ID payload with
 IP addresses as it is already done for the NAT traversal.

=3D> section 2.2 describes a NAT problem, not a NAT-PT problem.
I don't understand why section 3 doesn't try to extend the NAT traversal
mechanism...

=3D> section 4 doesn't make sense : IKE already works well through a =
NAT.

=3D> idem for section 5. If the only issue is the transport checksum
the current NAT traversal has NAT-OA payloads to fix it.

So my recommendation is to refer to RFC 3715 (IPsec-Network Address
Translation (NAT) Compatibility Requirements) and its companion solution
I-D draft-ietf-ipsec-nat-t-ike-08.txt

Regards

Francis.Dupont@enst-bretagne.fr





From owner-v6ops@ops.ietf.org  Tue Nov  2 01:21:10 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01866
	for <v6ops-archive@lists.ietf.org>; Tue, 2 Nov 2004 01:21:09 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1COs2L-000Ctt-36
	for v6ops-data@psg.com; Tue, 02 Nov 2004 06:20:57 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1COs2J-000CtW-Im
	for v6ops@ops.ietf.org; Tue, 02 Nov 2004 06:20:56 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id iA26Kn903948;
	Tue, 2 Nov 2004 08:20:50 +0200
Date: Tue, 2 Nov 2004 08:20:49 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: Soohong Daniel Park <soohong.park@samsung.com>
cc: v6ops@ops.ietf.org, jordi.palet@consulintel.es, Dhcwg <dhcwg@ietf.org>
Subject: RE: DHCP issue in draft-palet-v6ops-solution-tun-auto-disc-01.txt
In-Reply-To: <EDELKJDGPGNIPOAOHMNPIEAFGJAA.soohong.park@samsung.com>
Message-ID: <Pine.LNX.4.61.0411020816400.3339@netcore.fi>
References: <EDELKJDGPGNIPOAOHMNPIEAFGJAA.soohong.park@samsung.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

On Tue, 2 Nov 2004, Soohong Daniel Park wrote:
>> I'm not considering DHCP at all. May be need to be further
>> clarified. Is one more option, but more related, in my opinion,
>> to very controlled networks where you are sure that DHCP
>> options are relayed. We can even delete this section if it
>> creates confusion.
>
> *controlled networks* is also important domain for adopting
> IPv6 widely, especially enterprise network is entirely controlled
> by network administrator. Also enabling DHCP is quite normal,
> cheap and a widely deployed scenario. This solution works
> very well within our enterprise network.

I've no doubt it works within an enterprise network, but because it 
does not work under all the major scenarios (for example, over 
dial-ups, ADSLs, over VPN or v6-in-[udp]v4 tunnels, etc. where you 
don't run DHCP, and not necessarilily even PPP), the real question is: 
"is DHCP a sufficiently convincing method in a subset of all scenarios 
for configuration of the tunnel endpoint?"

DNS works under every scenario.  DHCP provides a slightly more 
customization per client but I'm sceptical whether this is 
an actual necessity.

-- 
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 owner-v6ops@ops.ietf.org  Tue Nov  2 06:02:41 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06658
	for <v6ops-archive@lists.ietf.org>; Tue, 2 Nov 2004 06:02:40 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1COwOR-0001UW-S9
	for v6ops-data@psg.com; Tue, 02 Nov 2004 11:00:03 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1COwOQ-0001TC-FB
	for v6ops@ops.ietf.org; Tue, 02 Nov 2004 11:00:02 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id iA2B00F10811
	for <v6ops@ops.ietf.org>; Tue, 2 Nov 2004 13:00:00 +0200
Date: Tue, 2 Nov 2004 13:00:00 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: v6ops@ops.ietf.org
Subject: POLL: SPs' IPv6 (tunnel) deployment requirements (fwd)
Message-ID: <Pine.LNX.4.61.0411021259210.10093@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

FYI -- let's see if we manage to get any SP operator feedback on 
tunneling requirements...

---------- Forwarded message ----------
Date: Tue, 2 Nov 2004 12:59:00 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: nanog@nanog.org
Subject: POLL: SPs' IPv6 (tunnel) deployment requirements

Hi,

(To avoid a lot of spamming on nanog, please send the replies to me off-list 
and I can summarize, or only to v6ops@ops.ietf.org if you think it deserves 
wider attention.)

IPv6 Operations WG at IETF is considering requirements and scenarios for 
v6-in-[udp]v4 solutions, especially as would be deployed by ISPs.

Unfortunately, there has been rather low amount of feedback from the operators, 
and we'll need more to find solutions that are actually close to what the 
operators want.. so, I'm trying here.. Please respond within a week or so.

A couple of questions (no need to answer to all if you don't want to):

  1. have you yet made plans how to deploy IPv6 towards
    (home) customers?
    a/ If yes, have you planned to use (only) dual-stack?
    b/ If yes, have you planned to use some form of tunneling?
    c/ If yes, using both as appropriate?

[[ The rest are relevant only with 1.b) or 1.c) ]]
  2. are you currently using L2TP or some other infrastructure for
     IPv4?
    a/ Is that adaptable to IPv6 (e.g., by adding v6 support to PPP)?
    b/ If yes, would it be a sufficient solution for your needs.  If
       not, please elaborate?

  3. in case L2TP is not done towards v4 customers now, have you
     planned or would you be interested in deploying v6 tunneling
     towards customers?
    a/ for free? (added value, competitional advantage, etc.)
    b/ for a fee?

  4. what would be your requirements for 3)?  Please elaborate a bit.
    For example, are some (which ones?) of the following relevant:
    - need to be used for own customers only
    - authentication based on IP addresses or similar
    - must it be capable to offer service to non-customers or roaming
      own customers through some registration process?
    - capability for doing prefix delegation to the customers
    - must work through a NAT (e.g., non-upgraded CPE)
    - should be possible to deploy multiple boxes easily
    - should be capable of v4-in-v6 tunneling also

  5. any other comments or questions?
    - shoot!

...

The two existing requirements documents, for two slightly different problem 
spaces (first for "easy set-up within your access network", the second 
"registered, more complicated mode for more extensive use"), are the following:

http://www.v6ops.euro6ix.net/ietf/draft-suryanarayanan-v6ops-zeroconf-reqs-01.txt
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-assisted-tunneling-requirements-01.txt

For a lengthier document describing BB ISP IPv6 deployment options, see:

http://www.ietf.org/internet-drafts/draft-asadullah-v6ops-bb-deployment-scenarios-01.txt

Feedback on these is also welcome, of course!

-- 
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 owner-v6ops@ops.ietf.org  Tue Nov  2 07:22:02 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12187
	for <v6ops-archive@lists.ietf.org>; Tue, 2 Nov 2004 07:22:02 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1COxe8-000Dhf-RI
	for v6ops-data@psg.com; Tue, 02 Nov 2004 12:20:20 +0000
Received: from [131.228.20.21] (helo=mgw-x1.nokia.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1COxdz-000Dfq-HB
	for v6ops@ops.ietf.org; Tue, 02 Nov 2004 12:20:11 +0000
Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159])
	by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA2CK8300350;
	Tue, 2 Nov 2004 14:20:08 +0200 (EET)
X-Scanned: Tue, 2 Nov 2004 14:20:01 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE
Received: (from root@localhost)
	by esdks004.ntc.nokia.com (8.12.9/8.12.9) id iA2CK15H006082;
	Tue, 2 Nov 2004 14:20:01 +0200
Received: from mgw-int2.ntc.nokia.com (172.21.143.97)
	by esdks004.ntc.nokia.com 00vRSkIU; Tue, 02 Nov 2004 14:20:01 EET
Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28])
	by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA2CK0S01870;
	Tue, 2 Nov 2004 14:20:00 +0200 (EET)
Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881);
	 Tue, 2 Nov 2004 14:18:05 +0200
Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881);
	 Tue, 2 Nov 2004 14:18:05 +0200
Received: from esebe054.NOE.Nokia.com ([172.21.143.44]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881);
	 Tue, 2 Nov 2004 14:18:04 +0200
Received: ESEBE054.noe.nokia.com 172.21.143.44 from 172.21.155.43 172.21.155.43 via HTTP with MS-WebStorage 6.0.6249
Received: from essrv103nok15543.ntc.nokia.com by ESEBE054.noe.nokia.com; 02 Nov 2004 14:18:04 +0200
Subject: Re: draft-nielsen-v6ops-3GPP-zeroconf-goals-00.txt
From: "Soininen Jonne (Nokia-NET/Helsinki)" <jonne.soininen@nokia.com>
To: the otter <2the.otter@gmail.com>
Cc: karen.e.neilsen@ericsson.com, v6ops@ops.ietf.org
In-Reply-To: <1774621e041101144514ded4b5@mail.gmail.com>
References: <1774621e041101144514ded4b5@mail.gmail.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1099397883.4890.32.camel@essrv103nok15543.ntc.nokia.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.6 
Date: Tue, 02 Nov 2004 14:18:03 +0200
X-OriginalArrivalTime: 02 Nov 2004 12:18:04.0563 (UTC) FILETIME=[01018E30:01C4C0D6]
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hello,

(Chair hat on)
It would be nice if you could identify yourself. It is not nice to
discuss on this kind of list with anonymous people.
(Chair hat off)

Below I have put some comments:
On Tue, 2004-11-02 at 00:45, ext the otter wrote:
> Hi Karen,
> Regarding the draft draft-nielsen-v6ops-3GPP-zeroconf-goals-00.txt, I
> would like to ask about push functionality and user identity within
> the 3GPP network.
> PUSH relates to tunnel duration/accessibility:
> 
> >6.7. Tunnel Link Sustainability
> >
> >  The tunnel link established in between a host deploying Zero-
> >  Configuration Tunneling and an associated Tunnel Server should be
> >  expected to remain in administrative active state for the lifetime of
> >  the IPv6 address provided to the host.
> >
> >  The tunnel protocol must not mandate keep-alive messages to be
> >  transmitted by the host simply in order to sustain tunnel link
> >  connectivity.
> 
> Is it intended that the tunnel remain up while the UE has an active
> PDP context?
> In an "always-on" network there may be services that perform PUSH
> (i.e. server initiated) functions - is it a requirement to allow IP PUSH from
> the IPv6 domain toward the client?
> I would suggest that this be a requirement or it will limit the
> service use cases for this solution.
> The PUSH functionality leads on to the User Identity issue which
> relates mainly to this section:
> 

I think the requirement is that the IPv6 address supports "always-on".
Thus, keeping the IPv6 address relatively stable - at least the IPv6
address has to be as table as the IPv4 address.
In addition, I don't think there are any restrictions on what kind of
protocols/services/applications are used over the tunnel.

> >6.6. Address Assignment
> >
> >  The tunnel protocol must allow for the assignment of at least one
> >  globally routable (/128) IPv6 unicast address to use for tunneled
> >  IPv6 connectivity over the link provided by the Zero-Configuration
> >  Tunneling mechanism.
> 
> 3GPP networks may utilise a database that combines authentication and
> DHCP functions (RADIUS + database). This ensures there is an
> authoritative system that can provide "User Identity", that is to say link
> IP address to User Account. A service can then query the data base to
> resolve an IP address to a User account or vice versa. Is the IPv6
> address assignment for the tunnel client compatible with this model?
> If this is not provided then some types of services in the IPv6 domain
> will not work. May I suggest that maintaining user ID mapping via IP
> address be a goal.
> If these are not to be goals then perhaps this could be stated.

The 3GPP operator may choose to use this kind of information in their
networks. However, usage of these mechanisms are to my understanding
optional in the 3GPP specifications (29.061). I don't know anyways what
would be the use case for doing this kind of IP address to MSISDN
mapping.

It may be more difficult to map the tunneled IPv6 address to the MSISDN
of the user, but most probably doable.

If there is a need to have _exactly_ the same functionality as in native
IPv4, it is better to use native IPv6 over GPRS. 
> 
> IMHO the issue I see with leaving these out is the transition mechanism
> becomes a solution for only the most basic of "web" type services.
> While this makes the solution simple, it removes the motivation for
> IPv6 within the 3GPP network. It is important to at least match or
> mimic the functionality available in the IPv4 domain.

The tunneling mechanism has to support stable addressing - that's right.
That is absolutely necessary. However, I don't understand this IP
address to MSISDN mapping requirement as that information is not
available outside the operators network anyways.

Cheers,

Jonne.

> 
> Best Regards,
> N
-- 
Jonne Soininen
Nokia

Tel: +358 40 527 46 34
E-mail: jonne.soininen@nokia.com



From owner-v6ops@ops.ietf.org  Tue Nov  2 07:41:58 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14501
	for <v6ops-archive@lists.ietf.org>; Tue, 2 Nov 2004 07:41:58 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1COxx2-000GUn-Gx
	for v6ops-data@psg.com; Tue, 02 Nov 2004 12:39:52 +0000
Received: from [193.180.251.49] (helo=albatross.ericsson.se)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1COxx1-000GUS-2E
	for v6ops@ops.ietf.org; Tue, 02 Nov 2004 12:39:51 +0000
Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120])
	by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id iA2CdnWR021867
	for <v6ops@ops.ietf.org>; Tue, 2 Nov 2004 13:39:50 +0100 (MET)
Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211);
	 Tue, 2 Nov 2004 13:39:48 +0100
Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id VJQGTVVG; Tue, 2 Nov 2004 13:39:48 +0100
Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <VJQGM57B>; Tue, 2 Nov 2004 13:39:48 +0100
Message-ID: <C26BB8276599A44B85D52F9CE41035E1050B97F1@esealnt944.al.sw.ericsson.se>
X-Sybari-Trust: 0e459f33 ad48f3dd 47c08d8f 00000179
From: "Karen E. Nielsen (AH/LMD)" <karen.e.nielsen@ericsson.com>
To: "'the otter'" <2the.otter@gmail.com>, karen.e.neilsen@ericsson.com
Cc: v6ops@ops.ietf.org
Subject: RE: draft-nielsen-v6ops-3GPP-zeroconf-goals-00.txt
Date: Tue, 2 Nov 2004 13:39:43 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
X-OriginalArrivalTime: 02 Nov 2004 12:39:48.0362 (UTC) FILETIME=[0A217EA0:01C4C0D9]
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

Hi,

> Hi Karen,
> Regarding the draft draft-nielsen-v6ops-3GPP-zeroconf-goals-00.txt, I
> would like to ask about push functionality and user identity within
> the 3GPP network.
> PUSH relates to tunnel duration/accessibility:
> 
> >6.7. Tunnel Link Sustainability
> >
> >  The tunnel link established in between a host deploying Zero-
> >  Configuration Tunneling and an associated Tunnel Server should be
> >  expected to remain in administrative active state for the 
> lifetime of
> >  the IPv6 address provided to the host.
> >
> >  The tunnel protocol must not mandate keep-alive messages to be
> >  transmitted by the host simply in order to sustain tunnel link
> >  connectivity.
> 
> Is it intended that the tunnel remain up while the UE has an active
> PDP context?

Yes and no.

It is intended that the tunnel remains active for 
the lifetime of the address allocated. The latter which could be infinity,
but also a smaller time span, e.g. one day, one week, depending on operator policy.

The terminal would have to refresh the address/tunnel once the lifetime
expires.

(In the case of unlimited/infinite address lifetime, the answer to your question is yes.)

> In an "always-on" network there may be services that perform PUSH
> (i.e. server initiated) functions - is it a requirement to 
> allow IP PUSH from
> the IPv6 domain toward the client?

It is not intended to allow server initiated set-up of tunnels.

It is intended to support the run of various IMS services over the tunnels, though not 
services which rely on PDP context based IMS and GGSN interworking, e.g.
SBLP mechanisms over the Go interface. 

Services based on server initiated PDP context activation for media traffic will
not be supported.

> I would suggest that this be a requirement or it will limit the
> service use cases for this solution.
> The PUSH functionality leads on to the User Identity issue which
> relates mainly to this section:
> 
> >6.6. Address Assignment
> >
> >  The tunnel protocol must allow for the assignment of at least one
> >  globally routable (/128) IPv6 unicast address to use for tunnelled
> >  IPv6 connectivity over the link provided by the Zero-Configuration
> >  Tunneling mechanism.
> 
> 3GPP networks may utilise a database that combines authentication and
> DHCP functions (RADIUS + database). This ensures there is an
> authoritative system that can provide "User Identity", that 
> is to say link
> IP address to User Account. A service can then query the data base to
> resolve an IP address to a User account or vice versa. Is the IPv6
> address assignment for the tunnel client compatible with this model?
> If this is not provided then some types of services in the IPv6 domain
> will not work. May I suggest that maintaining user ID mapping via IP
> address be a goal.
> If these are not to be goals then perhaps this could be stated.
> 

The intend was that where ID and Ipv6 address mapping must be established, 
e.g. IMS registration ?, this must be done by the user.

> IMHO the issue I see with leaving these out is the transition 
> mechanism
> becomes a solution for only the most basic of "web" type services.
> While this makes the solution simple, it removes the motivation for
> IPv6 within the 3GPP network. It is important to at least match or
> mimic the functionality available in the IPv4 domain.
> 

Tunnelling in 3GPP is not intended to provide full emulation of 
the native IPv4 or native IPv6 services, since that would basically require
full dual IP support in all related 3GPP signalling interfaces.

BR, Karen

> Best Regards,
> N
> 



From owner-v6ops@ops.ietf.org  Tue Nov  2 08:21:27 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18092
	for <v6ops-archive@lists.ietf.org>; Tue, 2 Nov 2004 08:21:27 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1COyaH-000MgE-9y
	for v6ops-data@psg.com; Tue, 02 Nov 2004 13:20:25 +0000
Received: from [192.44.77.17] (helo=laposte.rennes.enst-bretagne.fr)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1COyaG-000Mfq-3O
	for v6ops@ops.ietf.org; Tue, 02 Nov 2004 13:20:24 +0000
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194])
	by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id iA2DKFo23810;
	Tue, 2 Nov 2004 14:20:15 +0100
Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id iA2DKFSj059105;
	Tue, 2 Nov 2004 14:20:16 +0100 (CET)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200411021320.iA2DKFSj059105@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: "Inseok Choi" <ischl@cns.ssu.ac.kr>
cc: v6ops@ops.ietf.org
Subject: Re: IPsec support for NAT-PT in IPv6 
In-reply-to: Your message of Tue, 02 Nov 2004 15:16:44 +0900.
             <200411020617.iA26GxNg026302@coliposte.enst-bretagne.fr> 
Date: Tue, 02 Nov 2004 14:20:15 +0100
X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

 In your previous mail you wrote:

   in 2.1 ==> My proposed mechanism was assume IKE using preshared key Phase.

=> preshared key with not predictable address doesn't work in main mode,
there is nothing to do to fix that because this is an intrinsic feature
(identity protection).

   If we can't IKE using use certificate, we should use IKE using other way.
   
   in IPsec using UDP encapsulation ==> NAT-PT can't apply to it.

=> why? UDP encapsulation is there to help header translation and is
not limited to NAT.

   If we use IPsec using UDP encapsulation in NAT-PT, NAT-PT server
   may send IPv4-in-IPv6 packet.

=> I can't see the problem: the user wants to protect and encapsulate
its IPv6 packet...

   However IPv4 node don't understand IPv6 packet.
   
=> so tunnel mode is not usable but transport is.

   Therefore, NAT traversal method can be applied to NAT-PT mechanism.
   
Regards
   
Francis.Dupont@enst-bretagne.fr



From owner-v6ops@ops.ietf.org  Tue Nov  2 08:38:34 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19459
	for <v6ops-archive@lists.ietf.org>; Tue, 2 Nov 2004 08:38:33 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1COyqm-000P11-E9
	for v6ops-data@psg.com; Tue, 02 Nov 2004 13:37:28 +0000
Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1COyql-000P0n-FA
	for v6ops@ops.ietf.org; Tue, 02 Nov 2004 13:37:27 +0000
Received: from sj-core-5.cisco.com (171.71.177.238)
  by sj-iport-1.cisco.com with ESMTP; 02 Nov 2004 05:49:55 -0800
X-BrightmailFiltered: true
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id iA2DbPcp016889;
	Tue, 2 Nov 2004 05:37:26 -0800 (PST)
Received: from rdroms-w2k01.cisco.com (sjc-vpn5-583.cisco.com [10.21.90.71])
	by flask.cisco.com (MOS 3.4.6-GR)
	with ESMTP id AMS63686;
	Tue, 2 Nov 2004 08:37:23 -0500 (EST)
Message-Id: <4.3.2.7.2.20041102083325.02a45ee0@flask.cisco.com>
X-Sender: rdroms@flask.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 02 Nov 2004 08:37:20 -0500
To: Pekka Savola <pekkas@netcore.fi>
From: Ralph Droms <rdroms@cisco.com>
Subject: Re: POLL: SPs' IPv6 (tunnel) deployment requirements (fwd)
Cc: v6ops@ops.ietf.org
In-Reply-To: <Pine.LNX.4.61.0411021259210.10093@netcore.fi>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

Pekka - you've aimed some interesting questions in a good direction.  Thanks.

Would you be willing to make the full text of any responses available in 
some form?  Perhaps forward responses directly to v6ops or post the 
responses on the v6ops web page?

- Ralph

At 01:00 PM 11/2/2004 +0200, Pekka Savola wrote:
>FYI -- let's see if we manage to get any SP operator feedback on tunneling 
>requirements...
>
>---------- Forwarded message ----------
>Date: Tue, 2 Nov 2004 12:59:00 +0200 (EET)
>From: Pekka Savola <pekkas@netcore.fi>
>To: nanog@nanog.org
>Subject: POLL: SPs' IPv6 (tunnel) deployment requirements
>
>Hi,
>
>(To avoid a lot of spamming on nanog, please send the replies to me 
>off-list and I can summarize, or only to v6ops@ops.ietf.org if you think 
>it deserves wider attention.)
>
>IPv6 Operations WG at IETF is considering requirements and scenarios for 
>v6-in-[udp]v4 solutions, especially as would be deployed by ISPs.
>
>Unfortunately, there has been rather low amount of feedback from the 
>operators, and we'll need more to find solutions that are actually close 
>to what the operators want.. so, I'm trying here.. Please respond within a 
>week or so.
>
>A couple of questions (no need to answer to all if you don't want to):
>
>  1. have you yet made plans how to deploy IPv6 towards
>    (home) customers?
>    a/ If yes, have you planned to use (only) dual-stack?
>    b/ If yes, have you planned to use some form of tunneling?
>    c/ If yes, using both as appropriate?
>
>[[ The rest are relevant only with 1.b) or 1.c) ]]
>  2. are you currently using L2TP or some other infrastructure for
>     IPv4?
>    a/ Is that adaptable to IPv6 (e.g., by adding v6 support to PPP)?
>    b/ If yes, would it be a sufficient solution for your needs.  If
>       not, please elaborate?
>
>  3. in case L2TP is not done towards v4 customers now, have you
>     planned or would you be interested in deploying v6 tunneling
>     towards customers?
>    a/ for free? (added value, competitional advantage, etc.)
>    b/ for a fee?
>
>  4. what would be your requirements for 3)?  Please elaborate a bit.
>    For example, are some (which ones?) of the following relevant:
>    - need to be used for own customers only
>    - authentication based on IP addresses or similar
>    - must it be capable to offer service to non-customers or roaming
>      own customers through some registration process?
>    - capability for doing prefix delegation to the customers
>    - must work through a NAT (e.g., non-upgraded CPE)
>    - should be possible to deploy multiple boxes easily
>    - should be capable of v4-in-v6 tunneling also
>
>  5. any other comments or questions?
>    - shoot!
>
>...
>
>The two existing requirements documents, for two slightly different 
>problem spaces (first for "easy set-up within your access network", the 
>second "registered, more complicated mode for more extensive use"), are 
>the following:
>
>http://www.v6ops.euro6ix.net/ietf/draft-suryanarayanan-v6ops-zeroconf-reqs-01.txt
>http://www.ietf.org/internet-drafts/draft-ietf-v6ops-assisted-tunneling-requirements-01.txt
>
>For a lengthier document describing BB ISP IPv6 deployment options, see:
>
>http://www.ietf.org/internet-drafts/draft-asadullah-v6ops-bb-deployment-scenarios-01.txt
>
>Feedback on these is also welcome, of course!
>
>--
>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 owner-v6ops@ops.ietf.org  Tue Nov  2 08:42:44 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19822
	for <v6ops-archive@lists.ietf.org>; Tue, 2 Nov 2004 08:42:44 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1COyvM-000PrM-Fq
	for v6ops-data@psg.com; Tue, 02 Nov 2004 13:42:12 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1COyvK-000Pqj-H8
	for v6ops@ops.ietf.org; Tue, 02 Nov 2004 13:42:11 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id iA2Dg6815086;
	Tue, 2 Nov 2004 15:42:07 +0200
Date: Tue, 2 Nov 2004 15:42:06 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: Ralph Droms <rdroms@cisco.com>
cc: v6ops@ops.ietf.org
Subject: Re: POLL: SPs' IPv6 (tunnel) deployment requirements (fwd)
In-Reply-To: <4.3.2.7.2.20041102083325.02a45ee0@flask.cisco.com>
Message-ID: <Pine.LNX.4.61.0411021540110.14885@netcore.fi>
References: <4.3.2.7.2.20041102083325.02a45ee0@flask.cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

On Tue, 2 Nov 2004, Ralph Droms wrote:
> Pekka - you've aimed some interesting questions in a good direction.  Thanks.
>
> Would you be willing to make the full text of any responses 
> available in some form?  Perhaps forward responses directly to v6ops 
> or post the responses on the v6ops web page?

The responses might be subject to anonymity/confidentiality, but I'll 
see what I can do depending on the responses obtained during the week.

Certainly if there are a lot of responses there will be interesting 
data points beyond the tunnel deployment requirements.

-- 
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 owner-v6ops@ops.ietf.org  Tue Nov  2 09:54:45 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26188
	for <v6ops-archive@lists.ietf.org>; Tue, 2 Nov 2004 09:54:45 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CP01x-000BEX-IF
	for v6ops-data@psg.com; Tue, 02 Nov 2004 14:53:05 +0000
Received: from [209.71.226.3] (helo=panoramix.hexago.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CP01t-000BDr-Dj
	for v6ops@ops.ietf.org; Tue, 02 Nov 2004 14:53:01 +0000
Received: from dhcp-118.226.71.209.hexago.com (dhcp-118.226.71.209.hexago.com [209.71.226.118] (may be forged))
	(authenticated bits=0)
	by panoramix.hexago.com (8.12.8/8.12.8) with ESMTP id iA2ErTIY012708;
	Tue, 2 Nov 2004 09:53:29 -0500 (EST)
Date: Tue, 02 Nov 2004 09:52:52 -0500
From: Florent Parent <Florent.Parent@hexago.com>
To: "Karen E. Nielsen (AH/LMD)" <karen.e.nielsen@ericsson.com>,
        v6ops@ops.ietf.org
Subject: RE: I-D
 ACTION:draft-ietf-v6ops-assisted-tunneling-requirements-0	1.txt
Message-ID: <D111866369F5EE4A67A11ADC@[192.168.31.2]>
In-Reply-To: <C26BB8276599A44B85D52F9CE41035E1050B97E4@esealnt944.al.sw.ericsson.se>
References: <C26BB8276599A44B85D52F9CE41035E1050B97E4@esealnt944.al.sw.erics
 son.se>
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit



-- On Monday, November 01, 2004 11:11:28 +0100, Karen E. Nielsen (AH/LMD) 
wrote:

> One comment:
>
> The following paragraph of Section 1 should be made clearer,
> I think.
>
> "Contrary to automatic tunneling mechanism where the IPv4 address is
>    embedded inside the IPv6 address, no special format are imposed on
>    the IPv6 address used in assisted tunneling.  Prefix delegation is
>    also possible.  As the addressing space used during the transition to
>    native remains the same, the customer routing, filtering, accounting
>    stay the same, and there is no need to maintain any kind of relay."
>
> If the intended meaning is to say that the IPv6 addresses used during
> transition must be usable also when the users has moved to native, this
> should be made clearer here as well as in Section 4.1.

What is intended here and in section 4.1 is to say that an ISP can use its 
own IPv6 address space from its initial deployment using this transition 
mechanism, up to native deployment (naturally). Section 4.1 refers to 
section 5.1 in [I-D.ietf-v6ops-isp-scenarios-analysis], where text can be 
found saying that it is preferable to use the ISP address space.

Would adding something like the following to the last sentence make this 
clearer?
"An ISP can use its own IPv6 address space using this transition mechanism. 
As the address space used during ..."



>
> Again if the above is the intended meaning, it is valid of course to note
> that  that this preclude mechanisms which rely on special encoding of the
> underlying Ipv4 in the Ipv6 addresses.

The following paragraph in the draft says: "assisted tunneling protocol 
negotiate the tunnel parameters and does not depend on having the IPv4 
address inside the IPv6 address, for example". The tunnel parameters are 
exchanged between the server and client. I don't rerally see and advantage 
in using special IPv6 address encoding if you don't have to. Unless I'm 
missing your point?

Thanks the feedback Karen.

Florent




From owner-v6ops@ops.ietf.org  Tue Nov  2 10:40:23 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02117
	for <v6ops-archive@lists.ietf.org>; Tue, 2 Nov 2004 10:40:22 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CP0kT-000Ixi-FM
	for v6ops-data@psg.com; Tue, 02 Nov 2004 15:39:05 +0000
Received: from [131.228.20.27] (helo=mgw-x4.nokia.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CP0kR-000IxG-Sr
	for v6ops@ops.ietf.org; Tue, 02 Nov 2004 15:39:04 +0000
Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121])
	by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA2Fd2l16917;
	Tue, 2 Nov 2004 17:39:02 +0200 (EET)
X-Scanned: Tue, 2 Nov 2004 17:35:46 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE
Received: (from root@localhost)
	by esdks002.ntc.nokia.com (8.12.9/8.12.9) id iA2FZkux031913;
	Tue, 2 Nov 2004 17:35:46 +0200
Received: from mgw-int2.ntc.nokia.com (172.21.143.97)
	by esdks002.ntc.nokia.com 00VhRuAU; Tue, 02 Nov 2004 17:35:44 EET
Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84])
	by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA2FZiS06864;
	Tue, 2 Nov 2004 17:35:44 +0200 (EET)
Received: from esebe001.NOE.Nokia.com ([172.21.138.30]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881);
	 Tue, 2 Nov 2004 17:35:43 +0200
Received: from esebe054.NOE.Nokia.com ([172.21.143.44]) by esebe001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881);
	 Tue, 2 Nov 2004 17:35:43 +0200
Received: ESEBE054.noe.nokia.com 172.21.143.44 from 172.21.155.43 172.21.155.43 via HTTP with MS-WebStorage 6.0.6249
Received: from essrv103nok15543.ntc.nokia.com by ESEBE054.noe.nokia.com; 02 Nov 2004 17:35:43 +0200
Subject: Re: WG process etc. [Re: WG last call on tunneling scenarios]
From: "Soininen Jonne (Nokia-NET/Helsinki)" <jonne.soininen@nokia.com>
To: jordi.palet@consulintel.es
Cc: v6ops@ops.ietf.org
In-Reply-To: <BDAC9C87.4D34F%jordi.palet@consulintel.es>
References: <BDAC9C87.4D34F%jordi.palet@consulintel.es>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1099409742.4890.214.camel@essrv103nok15543.ntc.nokia.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.6 
Date: Tue, 02 Nov 2004 17:35:43 +0200
X-OriginalArrivalTime: 02 Nov 2004 15:35:43.0479 (UTC) FILETIME=[9D788870:01C4C0F1]
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Jordi,

I see that you are upset. I'm sorry if you feel that there has not been
enough discussion on the topic. 

However, we have been working in the process where we have to finish the
scenarios/analysis to understand what we are supposed to do. This has
been in place from the start of v6ops. Maybe there has not been enough
discussion on this process, but I feel the discussion now is a bit late.
We are practically finished! 

I hope we can discuss the next steps now in full extent in the meeting
to make sure that nobody's voice goes unheard.

Cheers,

Jonne.


On Tue, 2004-11-02 at 03:08, ext JORDI PALET MARTINEZ wrote:
> Hi Jonne,
> 
> Well, as you know, I think this serial-mode has been wrong all the time. At
> least a "pure-serial" mode.
> 
> I don't recall the WG being asked for doing this or not, just forced to.
> 
> Is that an open process ?
> 
> :-(
> 
> Regards,
> Jordi
> 
> 
> > De: "Soininen Jonne (Nokia-NET/Helsinki)" <jonne.soininen@nokia.com>
> > Responder a: owner-v6ops@ops.ietf.org
> > Fecha: Tue, 02 Nov 2004 00:36:28 +0200
> > Para: "ext Bound, Jim" <jim.bound@hp.com>
> > CC: jordi.palet@consulintel.es, v6ops@ops.ietf.org
> > Asunto: RE: WG process etc. [Re: WG last call on tunneling scenarios]
> > 
> > Ladies, and Gentlemen of the v6ops WG,
> > 
> > I understand that the slow process of our little WG causes some
> > frustration among the participants of the WG.
> > 
> > Like you all know, we have had this scenarios/analysis project going on
> > for a long time. To facilitate the quickest possible ending of that
> > project we decided in the IETF#60 meeting to concentrate on finishing
> > just those tasks. This has practically meant that much of the work has
> > concentrated on the remaining analysis document, and the now three
> > requirements documents.
> > 
> > Basically the plan was the following:
> > 
> > 1) Finish the remaining analysis documents
> > 2) Stabilize the requirements documents
> > 3) Map the requirements to solutions
> > 4) Refocus v6ops / start possibly needed work in the Internet Area
> > 
> > I think we are somewhere between steps 2 and 3, right?
> > 
> > I understand that people are anxious to start working on the actual
> > protocols - and believe me - I hope we could have started on the
> > technical work much earlier! However, sadly we just haven't gotten to
> > that point.
> > 
> > It is obvious that we have not communicated enough where are we going
> > and to some of you this has been an indication of us doing things behind
> > your backs. We'll try to behave better in the future. However, you
> > shouldn't worry at least Pekka and I plotting behind your backs - we
> > agree on so few things, it wouldn't be even possible! ;)
> > 
> > Cheers,
> > 
> > Jonne.
> > 
> > On Mon, 2004-11-01 at 22:28, ext Bound, Jim wrote:
> >> Jordi,
> >> 
> >>> On the other way around, I perfectly understand that industry is
> >> leading and some non-standards are
> >>> becoming de facto standards, which is not good.
> >>> That's why we need to work faster and in parallel instead of in serial
> >> and slow mode. If the WG is not
> >>> commenting or providing inputs, but there are no objections either, the
> >> work should be standardized.
> >> 
> >> This is your confusion and the IETF changed I think about 18 months ago
> >> or when we killed A6.  Specs cannot go forward from silence and that is
> >> now true in all IETF WGs I know of in the IETF.  I first ran into this
> >> in DHCPv6 working with Ralph as Chair many years ago.  I did not like it
> >> at first and did not get it.  Then we were able to get the engineers to
> >> comment on DHCPv6 and made the spec 10 times as strong and solid
> >> consensus.  So now I am a firm believer in silence is no good as metric
> >> to move a spec forward.  Zero conf work had lots of mail thread
> >> discussions and appears to be valid to accept as work item within the
> >> IETF.  Bottom line is the Chairs have not broken any rule but enforcing
> >> the rule.  Also sometimes the WG is just maxed.  For example we did not
> >> get input as fast as we needed it for Enterprise Analysis but then we go
> >> so much I am still parsing it as Ent Analysis editor.  I don't think
> >> there is any scientific method to this at all the longer I am around.
> >> 
> >> There is also no secret discussions that is just absurd.  Is it possible
> >> the ADs and Chairs individually don't support specific work, sure, but
> >> that's another matter and their right, and fair too.  The objective is
> >> to get the WG excited technically about specific work, and that makes
> >> the Chairs and ADs get a buzz.
> >> 
> >> Reqarding industry doing defacto standards.  Yes this is happening now
> >> with IPv6 Transition and several mechanisms are being deployed now that
> >> are way ahead of the IETF.  That will correct itself between the market
> >> and the IETF.  At times the market leads, but usually the IETF is in
> >> synch with the curve, but not on time. But, v6ops is doing everything it
> >> can to meet time-to-market and I for one applaud all of us here for that
> >> we are getting real work done and on time.  As you know I am very pro
> >> defacto standards and solutions when the IETF don't get it and a large
> >> number of implementers do. We just move forward in industry and keep
> >> sending data to this body called the IETF.  The IPv6 Forum is exactly
> >> from the IETF moving to slow and in 1999 implementors took matters into
> >> their own hands and now the IPv6 Forum is a world wide deployment body
> >> that clearly can support defacto standards and with task forces that are
> >> part of the IPv6 Forum across the planet.  That is what happens when any
> >> standards body is to slow and does not meet the needs of the market.
> >> 
> >> I read every mail on this list and a few others and you have not been
> >> treated unfairly at all, but your work has not reached consenus on this
> >> list that I can see as working group items.  That does not mean it is
> >> not good work but maybe not work in the IETF, as a question?  Ask your
> >> self is it a protocol, operational tool that can be standard without
> >> forcing implementation of protocols through configuration, a best
> >> current practice, etc.?  And most important "what problem does your work
> >> solve"?  
> >> 
> >> What I have found with my work in the IETF when it stalls it is usually
> >> there was no consensus on the problem it solves or there needs to first
> >> be discussion of everyones assumptions.  For example, I believe many
> >> customers will simply shut off IPv4 on a dual IPv4/IPv6 subnetwork and
> >> cascade that policy expediently as a transition strategy across all
> >> their other subnetworks until the entire customers Intranet or Internet
> >> is IPv6 dominant with only pockets of legacy IPv4 for transition.
> >> Educating all why and how is what I am doing now and once they see that
> >> then solving the problem can move forward.  I also think most customers
> >> now will go get IPv6 prefixes and 6to4 is highly questionable as widely
> >> used for the transition and that is a new change in the market some of
> >> us have learned directly.  These are just examples of others who have
> >> the same problem and I don't think it is because of secret meetings in
> >> the IETF.
> >> 
> >> I don't think the chairs or ADs warrant your mail and its unfair as one
> >> working group members input these chairs work their ass off and do what
> >> they can to keep things moving.  Now if they don't listen or ignore
> >> consensus I will be the first to throw tomatoes, but I don't see that in
> >> this specific case.
> >> 
> >> P.S. Pekka - I still do not agree with you about 70% of the time :--)
> >> 
> >> Regards,
> >> /jim
> >> 
> >> 
> > -- 
> > Jonne Soininen
> > Nokia
> > 
> > Tel: +358 40 527 46 34
> > E-mail: jonne.soininen@nokia.com
> > 
> > 
> 
> 
> 
> **********************************
> 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.
> 
> 
-- 
Jonne Soininen
Nokia

Tel: +358 40 527 46 34
E-mail: jonne.soininen@nokia.com



From owner-v6ops@ops.ietf.org  Tue Nov  2 11:52:12 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10458
	for <v6ops-archive@lists.ietf.org>; Tue, 2 Nov 2004 11:52:12 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CP1s3-0004w0-Ps
	for v6ops-data@psg.com; Tue, 02 Nov 2004 16:50:59 +0000
Received: from [213.172.48.142] (helo=consulintel.es)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CP1rm-0004sq-BB
	for v6ops@ops.ietf.org; Tue, 02 Nov 2004 16:50:42 +0000
Received: from [192.168.0.103] ([150.254.185.155])
	by consulintel.es (consulintel.es [127.0.0.1])
	(MDaemon.PRO.v7.2.0.R)
	with ESMTP id md50000546403.msg
	for <v6ops@ops.ietf.org>; Tue, 02 Nov 2004 17:56:06 +0100
User-Agent: Microsoft-Entourage/10.1.4.030702.0
Date: Tue, 02 Nov 2004 17:50:33 +0100
Subject: Re: WG last call on tunneling scenarios
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: <v6ops@ops.ietf.org>
Message-ID: <BDAD7969.4D5AA%jordi.palet@consulintel.es>
In-Reply-To: <20041102055050.GA23685@nokia.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Spam-Processed: consulintel.es, Tue, 02 Nov 2004 17:56:06 +0100
	(not processed: message from valid local sender)
X-MDRemoteIP: 150.254.185.155
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ops.ietf.org
Reply-To: jordi.palet@consulintel.es
X-MDAV-Processed: consulintel.es, Tue, 02 Nov 2004 17:56:08 +0100
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi David,

Well, is how I feel it. Is long to explain here, and probably not worth to
do it and continue this thread (unless you ask for it explicitly, then no
problem from my side), but I will be happy to talk to you and the chairs
during the meeting, if you have some time.

Anyway, as you said, you talked about the future of the WG, which clearly is
relevant for the WG itself, right ?

In my opinion, it will be much more useful, instead of just talking about it
during the meeting (and more fair because some people could not attend), to
open this thread NOW in the mail exploder, with any suggestions that you,
the chairs, whoever can have.

At this way, the WG can start thinking on it, providing inputs (hopefully),
and have a more clear and open discussion in the meeting, and then I guess a
final decision immediately after in the mailing list.

Also, reading one of the recent emails from Pekka, it seems to me that the
decision about asking the WG to get some documents as WG items (and not
others), has been taken, instead about asking the WG about all. I don't
agree with that procedure, while clearly it can be done more openly and the
WG can have a more fair decision (not a semi-driven one). But again, is my
point of view, which may be wrong, or different from others in the WG.

Regards,
Jordi


> De: David Kessens <david.kessens@nokia.com>
> Responder a: owner-v6ops@ops.ietf.org
> Fecha: Mon, 1 Nov 2004 21:50:50 -0800
> Para: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
> CC: v6ops@ops.ietf.org
> Asunto: Re: WG last call on tunneling scenarios
> 
> 
> Jordi,
> 
> On Sun, Oct 31, 2004 at 08:06:36PM +0100, JORDI PALET MARTINEZ wrote:
>> 
>> Let me explain. In general I feel that there is too much secret discussions
>> among the ADs and the co-chairs. I never understood why this talks doesn't
>> happen within the WG mail exploder, to get other inputs, ideas, or whatever
>> from the WG. Even if you only get a couple of them, they might be useful.
> 
> This is from far the truth and you know that. The things that we
> discuss privately are mostly about procedural issues and follow up on
> documents that are in IESG review.
> 
> The only topic outside this category that we recently talked about is
> the future of the working group. I already mentioned at last IETF
> meeting that this a topic is soon going to be important for the simple
> reason that most work items are now close to completion. Normally, in
> the life of an IETF working group, that is a good time to start
> thinking about what is next. Note that the discussions that we had
> were *not* to make decisions, they were intended to explore the
> various options that exist.
> 
> In order to discuss this further in all openness we asked the chairs
> to allocate some time on the agenda to talk about this:
> 
> ---
> Discussion of the way forward - 15 mins, Chairs/ADs
> - GOAL: discuss and get consensus on how to proceed from here
> ---
> 
> (and yes, I think we could possibly use a bit more than 15 minutes :-))
> 
>> So, I absolutely disagree with the way the decisions are being taken. This
>> is not consensus, is probably something closer to a semi-dictatorial
>> process, and don't take me wrong, you know that I don't have anything
>> personally against anyone, ADs and co-chairs included, but I prefer much
>> more being honest, open and clear.
> 
> This paragraph is very close to accusing the ADs and the co-chairs of
> dishonesty. I hope you tried to say something different :-).
> 
> David Kessens
> ---
> 
> 



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






From owner-v6ops@ops.ietf.org  Tue Nov  2 12:16:25 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13627
	for <v6ops-archive@lists.ietf.org>; Tue, 2 Nov 2004 12:16:24 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CP2Fr-000927-Ut
	for v6ops-data@psg.com; Tue, 02 Nov 2004 17:15:35 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CP2Fq-00091a-PT
	for v6ops@ops.ietf.org; Tue, 02 Nov 2004 17:15:35 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id iA2HFEk20155;
	Tue, 2 Nov 2004 19:15:14 +0200
Date: Tue, 2 Nov 2004 19:15:14 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: "Karen E. Nielsen (AH/LMD)" <karen.e.nielsen@ericsson.com>
cc: "'the otter'" <2the.otter@gmail.com>, karen.e.neilsen@ericsson.com,
        v6ops@ops.ietf.org
Subject: RE: draft-nielsen-v6ops-3GPP-zeroconf-goals-00.txt
In-Reply-To: <C26BB8276599A44B85D52F9CE41035E1050B97F1@esealnt944.al.sw.ericsson.se>
Message-ID: <Pine.LNX.4.61.0411021910040.20018@netcore.fi>
References: <C26BB8276599A44B85D52F9CE41035E1050B97F1@esealnt944.al.sw.ericsson.se>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

On Tue, 2 Nov 2004, Karen E. Nielsen (AH/LMD) wrote:
>> IMHO the issue I see with leaving these out is the transition
>> mechanism
>> becomes a solution for only the most basic of "web" type services.
>> While this makes the solution simple, it removes the motivation for
>> IPv6 within the 3GPP network. It is important to at least match or
>> mimic the functionality available in the IPv4 domain.
>
> Tunnelling in 3GPP is not intended to provide full emulation of
> the native IPv4 or native IPv6 services, since that would basically require
> full dual IP support in all related 3GPP signalling interfaces.

Without knowing the details here, I'll have to personally join in the 
first mentioned sentiment: as far as I see it, the UE tunneling offers 
the operators and UE vendors the chance to pilot IPv6 application 
deployments etc. without requiring immediate upgrades in the 3GPP 
network.

Unless the tunneling can provide a reasonable means to test out at 
least some potential applications that could be realized with IPv6, 
then its applicability might be a bit questionable.

Remember, IPv6 isn't all that inrestesting just because of a dancing 
turtle on a web page ;-).  It needs to provide a way to deploy nice 
new applications.  Even though full functions of IPv6 were not yet 
realized with the tentative tunneling solution, IMHO it should provide 
at least basic means to deploy some novel IPv6 applications (e.g., 
relativng to peer-to-peer).

-- 
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 owner-v6ops@ops.ietf.org  Tue Nov  2 12:23:00 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14305
	for <v6ops-archive@lists.ietf.org>; Tue, 2 Nov 2004 12:22:59 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CP2Mh-000A4o-EF
	for v6ops-data@psg.com; Tue, 02 Nov 2004 17:22:39 +0000
Received: from [213.172.48.142] (helo=consulintel.es)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CP2Md-000A4D-8b
	for v6ops@ops.ietf.org; Tue, 02 Nov 2004 17:22:35 +0000
Received: from [192.168.0.103] ([150.254.185.155])
	by consulintel.es (consulintel.es [127.0.0.1])
	(MDaemon.PRO.v7.2.0.R)
	with ESMTP id md50000546577.msg
	for <v6ops@ops.ietf.org>; Tue, 02 Nov 2004 18:28:01 +0100
User-Agent: Microsoft-Entourage/10.1.4.030702.0
Date: Tue, 02 Nov 2004 18:22:24 +0100
Subject: Re: POLL: SPs' IPv6 (tunnel) deployment requirements
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: <v6ops@ops.ietf.org>
Message-ID: <BDAD80E0.4D5E9%jordi.palet@consulintel.es>
In-Reply-To: <4.3.2.7.2.20041102083325.02a45ee0@flask.cisco.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Spam-Processed: consulintel.es, Tue, 02 Nov 2004 18:28:01 +0100
	(not processed: message from valid local sender)
X-MDRemoteIP: 150.254.185.155
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ops.ietf.org
Reply-To: jordi.palet@consulintel.es
X-MDAV-Processed: consulintel.es, Tue, 02 Nov 2004 18:28:01 +0100
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Agree very good movement. I've forwarded it to other mail exploders where
some operators may provide inputs from other regions.

Regards,
Jordi


> De: Ralph Droms <rdroms@cisco.com>
> Responder a: owner-v6ops@ops.ietf.org
> Fecha: Tue, 02 Nov 2004 08:37:20 -0500
> Para: Pekka Savola <pekkas@netcore.fi>
> CC: v6ops@ops.ietf.org
> Asunto: Re: POLL: SPs' IPv6 (tunnel) deployment requirements (fwd)
> 
> Pekka - you've aimed some interesting questions in a good direction.  Thanks.
> 
> Would you be willing to make the full text of any responses available in
> some form?  Perhaps forward responses directly to v6ops or post the
> responses on the v6ops web page?
> 
> - Ralph
> 
> At 01:00 PM 11/2/2004 +0200, Pekka Savola wrote:
>> FYI -- let's see if we manage to get any SP operator feedback on tunneling
>> requirements...
>> 
>> ---------- Forwarded message ----------
>> Date: Tue, 2 Nov 2004 12:59:00 +0200 (EET)
>> From: Pekka Savola <pekkas@netcore.fi>
>> To: nanog@nanog.org
>> Subject: POLL: SPs' IPv6 (tunnel) deployment requirements
>> 
>> Hi,
>> 
>> (To avoid a lot of spamming on nanog, please send the replies to me
>> off-list and I can summarize, or only to v6ops@ops.ietf.org if you think
>> it deserves wider attention.)
>> 
>> IPv6 Operations WG at IETF is considering requirements and scenarios for
>> v6-in-[udp]v4 solutions, especially as would be deployed by ISPs.
>> 
>> Unfortunately, there has been rather low amount of feedback from the
>> operators, and we'll need more to find solutions that are actually close
>> to what the operators want.. so, I'm trying here.. Please respond within a
>> week or so.
>> 
>> A couple of questions (no need to answer to all if you don't want to):
>> 
>>  1. have you yet made plans how to deploy IPv6 towards
>>    (home) customers?
>>    a/ If yes, have you planned to use (only) dual-stack?
>>    b/ If yes, have you planned to use some form of tunneling?
>>    c/ If yes, using both as appropriate?
>> 
>> [[ The rest are relevant only with 1.b) or 1.c) ]]
>>  2. are you currently using L2TP or some other infrastructure for
>>     IPv4?
>>    a/ Is that adaptable to IPv6 (e.g., by adding v6 support to PPP)?
>>    b/ If yes, would it be a sufficient solution for your needs.  If
>>       not, please elaborate?
>> 
>>  3. in case L2TP is not done towards v4 customers now, have you
>>     planned or would you be interested in deploying v6 tunneling
>>     towards customers?
>>    a/ for free? (added value, competitional advantage, etc.)
>>    b/ for a fee?
>> 
>>  4. what would be your requirements for 3)?  Please elaborate a bit.
>>    For example, are some (which ones?) of the following relevant:
>>    - need to be used for own customers only
>>    - authentication based on IP addresses or similar
>>    - must it be capable to offer service to non-customers or roaming
>>      own customers through some registration process?
>>    - capability for doing prefix delegation to the customers
>>    - must work through a NAT (e.g., non-upgraded CPE)
>>    - should be possible to deploy multiple boxes easily
>>    - should be capable of v4-in-v6 tunneling also
>> 
>>  5. any other comments or questions?
>>    - shoot!
>> 
>> ...
>> 
>> The two existing requirements documents, for two slightly different
>> problem spaces (first for "easy set-up within your access network", the
>> second "registered, more complicated mode for more extensive use"), are
>> the following:
>> 
>> http://www.v6ops.euro6ix.net/ietf/draft-suryanarayanan-v6ops-zeroconf-reqs-01
>> .txt
>> http://www.ietf.org/internet-drafts/draft-ietf-v6ops-assisted-tunneling-requi
>> rements-01.txt
>> 
>> For a lengthier document describing BB ISP IPv6 deployment options, see:
>> 
>> http://www.ietf.org/internet-drafts/draft-asadullah-v6ops-bb-deployment-scena
>> rios-01.txt
>> 
>> Feedback on these is also welcome, of course!
>> 
>> --
>> Pekka Savola                 "You each name yourselves king, yet the
>> Netcore Oy                    kingdom bleeds."
>> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> 
> 
> 



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






From owner-v6ops@ops.ietf.org  Tue Nov  2 12:31:39 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15185
	for <v6ops-archive@lists.ietf.org>; Tue, 2 Nov 2004 12:31:39 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CP2Up-000BJM-RA
	for v6ops-data@psg.com; Tue, 02 Nov 2004 17:31:03 +0000
Received: from [213.172.48.142] (helo=consulintel.es)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CP2Ul-000BIZ-1O
	for v6ops@ops.ietf.org; Tue, 02 Nov 2004 17:30:59 +0000
Received: from [192.168.0.103] ([150.254.185.155])
	by consulintel.es (consulintel.es [127.0.0.1])
	(MDaemon.PRO.v7.2.0.R)
	with ESMTP id md50000546617.msg
	for <v6ops@ops.ietf.org>; Tue, 02 Nov 2004 18:36:21 +0100
User-Agent: Microsoft-Entourage/10.1.4.030702.0
Date: Tue, 02 Nov 2004 18:30:17 +0100
Subject: Re: WG process etc. [Re: WG last call on tunneling scenarios]
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: <v6ops@ops.ietf.org>
Message-ID: <BDAD82B9.4D5EF%jordi.palet@consulintel.es>
In-Reply-To: <1099409742.4890.214.camel@essrv103nok15543.ntc.nokia.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Spam-Processed: consulintel.es, Tue, 02 Nov 2004 18:36:21 +0100
	(not processed: message from valid local sender)
X-MDRemoteIP: 150.254.185.155
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ops.ietf.org
Reply-To: jordi.palet@consulintel.es
X-MDAV-Processed: consulintel.es, Tue, 02 Nov 2004 18:36:25 +0100
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Jonne,

I'm not upset about this specific issue, even if it seems so. I was upset
long time ago on this ;-) We need to look in a positive way. What was done
wrong, should be recognized, and not do the same error twice !

I know it was a decision (not the WG decision, and that's the problem !),
and is to late to change it, but NOW, we have an opportunity to do better
the next steps, at least with the WG agreement.

So please, start the discussion now in the list, provide inputs about what
are your proposing, different alternatives, etc.

The meeting is never enough (even with time restrictions, people not there
which may contribute, etc.), specially if the inputs aren't there up-front.

I think that should be a fair way to continue. Do you agree ?

Regards,
Jordi


> De: "Soininen Jonne (Nokia-NET/Helsinki)" <jonne.soininen@nokia.com>
> Responder a: owner-v6ops@ops.ietf.org
> Fecha: Tue, 02 Nov 2004 17:35:43 +0200
> Para: jordi.palet@consulintel.es
> CC: v6ops@ops.ietf.org
> Asunto: Re: WG process etc. [Re: WG last call on tunneling scenarios]
> 
> Jordi,
> 
> I see that you are upset. I'm sorry if you feel that there has not been
> enough discussion on the topic.
> 
> However, we have been working in the process where we have to finish the
> scenarios/analysis to understand what we are supposed to do. This has
> been in place from the start of v6ops. Maybe there has not been enough
> discussion on this process, but I feel the discussion now is a bit late.
> We are practically finished!
> 
> I hope we can discuss the next steps now in full extent in the meeting
> to make sure that nobody's voice goes unheard.
> 
> Cheers,
> 
> Jonne.
> 
> 
> On Tue, 2004-11-02 at 03:08, ext JORDI PALET MARTINEZ wrote:
>> Hi Jonne,
>> 
>> Well, as you know, I think this serial-mode has been wrong all the time. At
>> least a "pure-serial" mode.
>> 
>> I don't recall the WG being asked for doing this or not, just forced to.
>> 
>> Is that an open process ?
>> 
>> :-(
>> 
>> Regards,
>> Jordi
>> 
>> 
>>> De: "Soininen Jonne (Nokia-NET/Helsinki)" <jonne.soininen@nokia.com>
>>> Responder a: owner-v6ops@ops.ietf.org
>>> Fecha: Tue, 02 Nov 2004 00:36:28 +0200
>>> Para: "ext Bound, Jim" <jim.bound@hp.com>
>>> CC: jordi.palet@consulintel.es, v6ops@ops.ietf.org
>>> Asunto: RE: WG process etc. [Re: WG last call on tunneling scenarios]
>>> 
>>> Ladies, and Gentlemen of the v6ops WG,
>>> 
>>> I understand that the slow process of our little WG causes some
>>> frustration among the participants of the WG.
>>> 
>>> Like you all know, we have had this scenarios/analysis project going on
>>> for a long time. To facilitate the quickest possible ending of that
>>> project we decided in the IETF#60 meeting to concentrate on finishing
>>> just those tasks. This has practically meant that much of the work has
>>> concentrated on the remaining analysis document, and the now three
>>> requirements documents.
>>> 
>>> Basically the plan was the following:
>>> 
>>> 1) Finish the remaining analysis documents
>>> 2) Stabilize the requirements documents
>>> 3) Map the requirements to solutions
>>> 4) Refocus v6ops / start possibly needed work in the Internet Area
>>> 
>>> I think we are somewhere between steps 2 and 3, right?
>>> 
>>> I understand that people are anxious to start working on the actual
>>> protocols - and believe me - I hope we could have started on the
>>> technical work much earlier! However, sadly we just haven't gotten to
>>> that point.
>>> 
>>> It is obvious that we have not communicated enough where are we going
>>> and to some of you this has been an indication of us doing things behind
>>> your backs. We'll try to behave better in the future. However, you
>>> shouldn't worry at least Pekka and I plotting behind your backs - we
>>> agree on so few things, it wouldn't be even possible! ;)
>>> 
>>> Cheers,
>>> 
>>> Jonne.
>>> 
>>> On Mon, 2004-11-01 at 22:28, ext Bound, Jim wrote:
>>>> Jordi,
>>>> 
>>>>> On the other way around, I perfectly understand that industry is
>>>> leading and some non-standards are
>>>>> becoming de facto standards, which is not good.
>>>>> That's why we need to work faster and in parallel instead of in serial
>>>> and slow mode. If the WG is not
>>>>> commenting or providing inputs, but there are no objections either, the
>>>> work should be standardized.
>>>> 
>>>> This is your confusion and the IETF changed I think about 18 months ago
>>>> or when we killed A6.  Specs cannot go forward from silence and that is
>>>> now true in all IETF WGs I know of in the IETF.  I first ran into this
>>>> in DHCPv6 working with Ralph as Chair many years ago.  I did not like it
>>>> at first and did not get it.  Then we were able to get the engineers to
>>>> comment on DHCPv6 and made the spec 10 times as strong and solid
>>>> consensus.  So now I am a firm believer in silence is no good as metric
>>>> to move a spec forward.  Zero conf work had lots of mail thread
>>>> discussions and appears to be valid to accept as work item within the
>>>> IETF.  Bottom line is the Chairs have not broken any rule but enforcing
>>>> the rule.  Also sometimes the WG is just maxed.  For example we did not
>>>> get input as fast as we needed it for Enterprise Analysis but then we go
>>>> so much I am still parsing it as Ent Analysis editor.  I don't think
>>>> there is any scientific method to this at all the longer I am around.
>>>> 
>>>> There is also no secret discussions that is just absurd.  Is it possible
>>>> the ADs and Chairs individually don't support specific work, sure, but
>>>> that's another matter and their right, and fair too.  The objective is
>>>> to get the WG excited technically about specific work, and that makes
>>>> the Chairs and ADs get a buzz.
>>>> 
>>>> Reqarding industry doing defacto standards.  Yes this is happening now
>>>> with IPv6 Transition and several mechanisms are being deployed now that
>>>> are way ahead of the IETF.  That will correct itself between the market
>>>> and the IETF.  At times the market leads, but usually the IETF is in
>>>> synch with the curve, but not on time. But, v6ops is doing everything it
>>>> can to meet time-to-market and I for one applaud all of us here for that
>>>> we are getting real work done and on time.  As you know I am very pro
>>>> defacto standards and solutions when the IETF don't get it and a large
>>>> number of implementers do. We just move forward in industry and keep
>>>> sending data to this body called the IETF.  The IPv6 Forum is exactly
>>>> from the IETF moving to slow and in 1999 implementors took matters into
>>>> their own hands and now the IPv6 Forum is a world wide deployment body
>>>> that clearly can support defacto standards and with task forces that are
>>>> part of the IPv6 Forum across the planet.  That is what happens when any
>>>> standards body is to slow and does not meet the needs of the market.
>>>> 
>>>> I read every mail on this list and a few others and you have not been
>>>> treated unfairly at all, but your work has not reached consenus on this
>>>> list that I can see as working group items.  That does not mean it is
>>>> not good work but maybe not work in the IETF, as a question?  Ask your
>>>> self is it a protocol, operational tool that can be standard without
>>>> forcing implementation of protocols through configuration, a best
>>>> current practice, etc.?  And most important "what problem does your work
>>>> solve"?  
>>>> 
>>>> What I have found with my work in the IETF when it stalls it is usually
>>>> there was no consensus on the problem it solves or there needs to first
>>>> be discussion of everyones assumptions.  For example, I believe many
>>>> customers will simply shut off IPv4 on a dual IPv4/IPv6 subnetwork and
>>>> cascade that policy expediently as a transition strategy across all
>>>> their other subnetworks until the entire customers Intranet or Internet
>>>> is IPv6 dominant with only pockets of legacy IPv4 for transition.
>>>> Educating all why and how is what I am doing now and once they see that
>>>> then solving the problem can move forward.  I also think most customers
>>>> now will go get IPv6 prefixes and 6to4 is highly questionable as widely
>>>> used for the transition and that is a new change in the market some of
>>>> us have learned directly.  These are just examples of others who have
>>>> the same problem and I don't think it is because of secret meetings in
>>>> the IETF.
>>>> 
>>>> I don't think the chairs or ADs warrant your mail and its unfair as one
>>>> working group members input these chairs work their ass off and do what
>>>> they can to keep things moving.  Now if they don't listen or ignore
>>>> consensus I will be the first to throw tomatoes, but I don't see that in
>>>> this specific case.
>>>> 
>>>> P.S. Pekka - I still do not agree with you about 70% of the time :--)
>>>> 
>>>> Regards,
>>>> /jim
>>>> 
>>>> 
>>> -- 
>>> Jonne Soininen
>>> Nokia
>>> 
>>> Tel: +358 40 527 46 34
>>> E-mail: jonne.soininen@nokia.com
>>> 
>>> 
>> 
>> 
>> 
>> **********************************
>> 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.
>> 
>> 
> -- 
> Jonne Soininen
> Nokia
> 
> Tel: +358 40 527 46 34
> E-mail: jonne.soininen@nokia.com
> 
> 



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






From owner-v6ops@ops.ietf.org  Tue Nov  2 16:41:20 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18062
	for <v6ops-archive@lists.ietf.org>; Tue, 2 Nov 2004 16:41:19 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CP6Mh-000Mym-6N
	for v6ops-data@psg.com; Tue, 02 Nov 2004 21:38:55 +0000
Received: from [66.92.66.68] (helo=cyteen.hactrn.net)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CP6Mg-000MyO-7m
	for v6ops@ops.ietf.org; Tue, 02 Nov 2004 21:38:54 +0000
Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:250:daff:fe82:1c39])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK))
	by cyteen.hactrn.net (Postfix) with ESMTP id A0DD72B6
	for <v6ops@ops.ietf.org>; Tue,  2 Nov 2004 16:38:53 -0500 (EST)
Received: from thrintun.hactrn.net (localhost [IPv6:::1])
	by thrintun.hactrn.net (Postfix) with ESMTP id D661B41EA
	for <v6ops@ops.ietf.org>; Tue,  2 Nov 2004 16:38:52 -0500 (EST)
Date: Tue, 02 Nov 2004 16:38:52 -0500
From: Rob Austein <sra@isc.org>
To: v6ops@ops.ietf.org
Subject: Re: A, CNAME or both issue on	draft-palet-v6ops-solution-tun-auto-disc-01.txt
In-Reply-To: <BDAC9641.4D30C%jordi.palet@consulintel.es>
References: <BDA1A8D4.4B856%jordi.palet@consulintel.es>
	<BDAC9641.4D30C%jordi.palet@consulintel.es>
MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <20041102213852.D661B41EA@thrintun.hactrn.net>
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

If the question is "Is there any need to make an explicit CNAME query
when what one is really looking for is an A RR?", the answer is "No".



From owner-v6ops@ops.ietf.org  Tue Nov  2 23:45:54 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26383
	for <v6ops-archive@lists.ietf.org>; Tue, 2 Nov 2004 23:45:53 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CPCz6-0003Si-2J
	for v6ops-data@psg.com; Wed, 03 Nov 2004 04:43:00 +0000
Received: from [64.233.184.196] (helo=wproxy.gmail.com)
 	by psg.com with esmtp (Exim 4.41 (FreeBSD))
 	id 1CP8Ba-000CSb-36
 	for v6ops@ops.ietf.org; Tue, 02 Nov 2004 23:35:34 +0000
Received: by wproxy.gmail.com with SMTP id 45so305178wri
         for <v6ops@ops.ietf.org>; Tue, 02 Nov 2004 15:35:26 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
         s=beta; d=gmail.com;
         h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references;
         b=C/WXZePtljElvMV1EXZ+4BA3YW0KdPnI4bYEPhDhCfqf554ylat+XFBUsh0iR9uECHqf23wpylXUcdoJ8Yh1xkNJAZzaBseGrxB8UpAEvIowAqs1Y752LpoTimiEXeiayPJgfAKvGbF/wSdiRnmy7iiDtHUgs+C6HfINfNm7XwY=
Received: by 10.54.39.26 with SMTP id m26mr276512wrm;
         Tue, 02 Nov 2004 15:35:26 -0800 (PST)
Received: by 10.54.27.75 with HTTP; Tue, 2 Nov 2004 15:35:26 -0800 (PST)
Message-ID: <1774621e0411021535469fcb90@mail.gmail.com>
Date: Tue, 2 Nov 2004 23:35:26 +0000
From: the otter <2the.otter@gmail.com>
Reply-To: the otter <2the.otter@gmail.com>
To: "Karen E. Nielsen (AH/LMD)" <karen.e.nielsen@ericsson.com>
Subject: Re: draft-nielsen-v6ops-3GPP-zeroconf-goals-00.txt
Cc: v6ops@ops.ietf.org
In-Reply-To: <C26BB8276599A44B85D52F9CE41035E1050B97F1@esealnt944.al.sw.ericsson.se>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <C26BB8276599A44B85D52F9CE41035E1050B97F1@esealnt944.al.sw.ericsson.se>
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham
 	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

You have answered the PUSH question. If the tunnel remains up as long
as the terminal has an IP address then that is good. The server can
assume the tunnel is up if there is a valid IP to contact.

Thanks & Regards,


On Tue, 2 Nov 2004 13:39:43 +0100, Karen E. Nielsen (AH/LMD)
<karen.e.nielsen@ericsson.com> wrote:
> Hi,
>
>
>
>> Hi Karen,
>> Regarding the draft draft-nielsen-v6ops-3GPP-zeroconf-goals-00.txt, I
>> would like to ask about push functionality and user identity within
>> the 3GPP network.
>> PUSH relates to tunnel duration/accessibility:
>>
>>>6.7. Tunnel Link Sustainability
>>>
>>>  The tunnel link established in between a host deploying Zero-
>>>  Configuration Tunneling and an associated Tunnel Server should be
>>>  expected to remain in administrative active state for the
>> lifetime of
>>>  the IPv6 address provided to the host.
>>>
>>>  The tunnel protocol must not mandate keep-alive messages to be
>>>  transmitted by the host simply in order to sustain tunnel link
>>>  connectivity.
>>
>> Is it intended that the tunnel remain up while the UE has an active
>> PDP context?
>
> Yes and no.
>
> It is intended that the tunnel remains active for
> the lifetime of the address allocated. The latter which could be infinity,
> but also a smaller time span, e.g. one day, one week, depending on operator policy.
>
> The terminal would have to refresh the address/tunnel once the lifetime
> expires.
>
> (In the case of unlimited/infinite address lifetime, the answer to your question is yes.)
>
>> In an "always-on" network there may be services that perform PUSH
>> (i.e. server initiated) functions - is it a requirement to
>> allow IP PUSH from
>> the IPv6 domain toward the client?
>
> It is not intended to allow server initiated set-up of tunnels.
>
> It is intended to support the run of various IMS services over the tunnels, though not
> services which rely on PDP context based IMS and GGSN interworking, e.g.
> SBLP mechanisms over the Go interface.
>
> Services based on server initiated PDP context activation for media traffic will
> not be supported.
>
>> I would suggest that this be a requirement or it will limit the
>> service use cases for this solution.
>> The PUSH functionality leads on to the User Identity issue which
>> relates mainly to this section:
>>
>>>6.6. Address Assignment
>>>
>>>  The tunnel protocol must allow for the assignment of at least one
>>>  globally routable (/128) IPv6 unicast address to use for tunnelled
>
>
>>>  IPv6 connectivity over the link provided by the Zero-Configuration
>>>  Tunneling mechanism.
>>
>> 3GPP networks may utilise a database that combines authentication and
>> DHCP functions (RADIUS + database). This ensures there is an
>> authoritative system that can provide "User Identity", that
>> is to say link
>> IP address to User Account. A service can then query the data base to
>> resolve an IP address to a User account or vice versa. Is the IPv6
>> address assignment for the tunnel client compatible with this model?
>> If this is not provided then some types of services in the IPv6 domain
>> will not work. May I suggest that maintaining user ID mapping via IP
>> address be a goal.
>> If these are not to be goals then perhaps this could be stated.
>>
>
> The intend was that where ID and Ipv6 address mapping must be established,
> e.g. IMS registration ?, this must be done by the user.
>
>> IMHO the issue I see with leaving these out is the transition
>> mechanism
>> becomes a solution for only the most basic of "web" type services.
>> While this makes the solution simple, it removes the motivation for
>> IPv6 within the 3GPP network. It is important to at least match or
>> mimic the functionality available in the IPv4 domain.
>>
>
> Tunnelling in 3GPP is not intended to provide full emulation of
> the native IPv4 or native IPv6 services, since that would basically require
> full dual IP support in all related 3GPP signalling interfaces.
>
> BR, Karen
>
>> Best Regards,
>> N
>>
>



From owner-v6ops@ops.ietf.org  Wed Nov  3 04:43:50 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15732
	for <v6ops-archive@lists.ietf.org>; Wed, 3 Nov 2004 04:43:50 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CPHeb-000Iez-A1
	for v6ops-data@psg.com; Wed, 03 Nov 2004 09:42:09 +0000
Received: from [64.233.184.204] (helo=wproxy.gmail.com)
 	by psg.com with esmtp (Exim 4.41 (FreeBSD))
 	id 1CPHOw-000GWe-Ru
 	for v6ops@ops.ietf.org; Wed, 03 Nov 2004 09:25:58 +0000
Received: by wproxy.gmail.com with SMTP id 45so356968wri
         for <v6ops@ops.ietf.org>; Wed, 03 Nov 2004 01:25:57 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
         s=beta; d=gmail.com;
         h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references;
         b=IpTx03biu/2CRozW73ZN07hBf9XIjve3CZb1UfmazX3/MQIL2UjSibW5vxBbrAD1enlBQf3jlPV6oynEZjT86X2yxITEO0nAh0Auz5SXzT1x+o9FFfYeL7EmgJUec+PZe8rbmq+KiJwIMtjvrzjSgZM9j57DM3gXwiXb0Bv3c4M=
Received: by 10.54.27.11 with SMTP id a11mr312260wra;
         Wed, 03 Nov 2004 01:25:57 -0800 (PST)
Received: by 10.54.27.75 with HTTP; Wed, 3 Nov 2004 01:25:56 -0800 (PST)
Message-ID: <1774621e041103012565dad37f@mail.gmail.com>
Date: Wed, 3 Nov 2004 09:25:56 +0000
From: the otter <2the.otter@gmail.com>
Reply-To: the otter <2the.otter@gmail.com>
To: "Soininen Jonne (Nokia-NET/Helsinki)" <jonne.soininen@nokia.com>
Subject: Re: draft-nielsen-v6ops-3GPP-zeroconf-goals-00.txt
Cc: v6ops@ops.ietf.org
In-Reply-To: <1099397883.4890.32.camel@essrv103nok15543.ntc.nokia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <1774621e041101144514ded4b5@mail.gmail.com>
 	 <1099397883.4890.32.camel@essrv103nok15543.ntc.nokia.com>
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham
 	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi,
The reasons an operator may make use of IP address to account mapping
at a service is to:
- provide automatic sign-on to a service (-it would be annoying to
have to insert username/password on a handset everytime you use WAP or MMS)
- determine from the IP address something about the users settings (-
for example, have they requested Location Based Services to be turned
off)
- event based PUSH (-for example, a messaging server looks up user
account, obtains IP address and pushes email to terminal)

If we cannot assume any significance about the IPv6 address then these
functions must be achieved at a different layer. At the moment in
IPv4, there exists a consistent way of determining User ID from IP
address.

Sure, these solutions only exist in the operator networks (and
directly connected 3rd Party) but this is still important. The IP
address has a lot of significance within the internal network of the
operator. And I mean just the Gi network, forget all the others. With
regard transition methods, these play a significant part in the large
international operator's network, when you consider these are actually
a number of disjoint national operators' access-networks trying to
access common services.

It would be neat to continue the identity in the v6 domain. The
solution would just need to be deterministic. I purposely didn't want
to look at the solutions, and stick to goals, but we may think about:
1) a second IPv6 RADIUS/DHCP server for DHCP to tunnels which is
interrogated in the IPv6 domain (is this against the zero config goals?); or
2) use a PREFIX function (c.f. NAT-PT 96bit PREFIX) where IPv4 address
at source (and in the RADIUS DB) can be determined from the incoming
IPv6 address (perhaps security/fraud issues?)

Again, if this is not going to feature in this draft, can we state this.

Note on standards - I cannot see the 3GPP standardising the Gi in
anyway. However barring IMS this is where all the IP Services reside.
So IMHO I think the standards will not have all the answers, and
looking at what happens in practice is beneficial. But Is the
motivation for this draft IMS alone? I interpret "3GPP" to
mean this draft is applicable to mobile operator services generally,
not IMS alone.

Thanks & Regards,



On Tue, 02 Nov 2004 14:18:03 +0200, Soininen Jonne
(Nokia-NET/Helsinki) <jonne.soininen@nokia.com> wrote:
> Hello,
>
> (Chair hat on)
> It would be nice if you could identify yourself. It is not nice to
> discuss on this kind of list with anonymous people.
> (Chair hat off)
>
> Below I have put some comments:
>
>
> On Tue, 2004-11-02 at 00:45, ext the otter wrote:
>> Hi Karen,
>> Regarding the draft draft-nielsen-v6ops-3GPP-zeroconf-goals-00.txt, I
>> would like to ask about push functionality and user identity within
>> the 3GPP network.
>> PUSH relates to tunnel duration/accessibility:
>>
>>>6.7. Tunnel Link Sustainability
>>>
>>>  The tunnel link established in between a host deploying Zero-
>>>  Configuration Tunneling and an associated Tunnel Server should be
>>>  expected to remain in administrative active state for the lifetime of
>>>  the IPv6 address provided to the host.
>>>
>>>  The tunnel protocol must not mandate keep-alive messages to be
>>>  transmitted by the host simply in order to sustain tunnel link
>>>  connectivity.
>>
>> Is it intended that the tunnel remain up while the UE has an active
>> PDP context?
>> In an "always-on" network there may be services that perform PUSH
>> (i.e. server initiated) functions - is it a requirement to allow IP PUSH from
>> the IPv6 domain toward the client?
>> I would suggest that this be a requirement or it will limit the
>> service use cases for this solution.
>> The PUSH functionality leads on to the User Identity issue which
>> relates mainly to this section:
>>
>
> I think the requirement is that the IPv6 address supports "always-on".
> Thus, keeping the IPv6 address relatively stable - at least the IPv6
> address has to be as table as the IPv4 address.
> In addition, I don't think there are any restrictions on what kind of
> protocols/services/applications are used over the tunnel.
>
>
>
>>>6.6. Address Assignment
>>>
>>>  The tunnel protocol must allow for the assignment of at least one
>>>  globally routable (/128) IPv6 unicast address to use for tunneled
>>>  IPv6 connectivity over the link provided by the Zero-Configuration
>>>  Tunneling mechanism.
>>
>> 3GPP networks may utilise a database that combines authentication and
>> DHCP functions (RADIUS + database). This ensures there is an
>> authoritative system that can provide "User Identity", that is to say link
>> IP address to User Account. A service can then query the data base to
>> resolve an IP address to a User account or vice versa. Is the IPv6
>> address assignment for the tunnel client compatible with this model?
>> If this is not provided then some types of services in the IPv6 domain
>> will not work. May I suggest that maintaining user ID mapping via IP
>> address be a goal.
>> If these are not to be goals then perhaps this could be stated.
>
> The 3GPP operator may choose to use this kind of information in their
> networks. However, usage of these mechanisms are to my understanding
> optional in the 3GPP specifications (29.061). I don't know anyways what
> would be the use case for doing this kind of IP address to MSISDN
> mapping.
>
> It may be more difficult to map the tunneled IPv6 address to the MSISDN
> of the user, but most probably doable.
>
> If there is a need to have _exactly_ the same functionality as in native
> IPv4, it is better to use native IPv6 over GPRS.
>>
>> IMHO the issue I see with leaving these out is the transition mechanism
>> becomes a solution for only the most basic of "web" type services.
>> While this makes the solution simple, it removes the motivation for
>> IPv6 within the 3GPP network. It is important to at least match or
>> mimic the functionality available in the IPv4 domain.
>
> The tunneling mechanism has to support stable addressing - that's right.
> That is absolutely necessary. However, I don't understand this IP
> address to MSISDN mapping requirement as that information is not
> available outside the operators network anyways.
>
> Cheers,
>
> Jonne.
>
>>
>> Best Regards,
>> N
> --
> Jonne Soininen
> Nokia
>
> Tel: +358 40 527 46 34
> E-mail: jonne.soininen@nokia.com
>



From owner-v6ops@ops.ietf.org  Wed Nov  3 05:28:23 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19371
	for <v6ops-archive@lists.ietf.org>; Wed, 3 Nov 2004 05:28:22 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CPIMZ-00009I-Hm
	for v6ops-data@psg.com; Wed, 03 Nov 2004 10:27:35 +0000
Received: from [195.212.29.136] (helo=mtagate3.uk.ibm.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CPIMW-00008m-7A
	for v6ops@ops.ietf.org; Wed, 03 Nov 2004 10:27:34 +0000
Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185])
	by mtagate3.uk.ibm.com (8.12.10/8.12.10) with ESMTP id iA3ARReg156268;
	Wed, 3 Nov 2004 10:27:27 GMT
Received: from sihl.zurich.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228])
	by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iA3ARQEK165012;
	Wed, 3 Nov 2004 10:27:26 GMT
Received: from zurich.ibm.com (sig-9-145-131-110.de.ibm.com [9.145.131.110])
	by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA74932;
	Wed, 3 Nov 2004 11:27:25 +0100
Message-ID: <4188B28D.9070208@zurich.ibm.com>
Date: Wed, 03 Nov 2004 11:27:25 +0100
From: Brian E Carpenter <brc@zurich.ibm.com>
Organization: IBM
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en, fr, de
MIME-Version: 1.0
To: jordi.palet@consulintel.es
CC: v6ops@ops.ietf.org
Subject: Re: WG process etc. [Re: WG last call on tunneling scenarios]
References: <BDAD82B9.4D5EF%jordi.palet@consulintel.es>
In-Reply-To: <BDAD82B9.4D5EF%jordi.palet@consulintel.es>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Jordi,

 > I know it was a decision (not the WG decision, and that's the problem !),

I don't think that's the problem. Consider the job that the community
asks the ADs (i.e. the Steering Group) to do: steer the IETF. That's why
it's the IESG that approves WG charters. You can say that the IESG
steered incorrectly, but you can't say that they aren't allowed to
steer.

That is why WG charters are sent out for review - and people generally
don't comment on them, as far as I can see. When I was in the IAB,
I always felt that reviewing (IAB) and approving (IESG) charters was
the most important single activity of those committees.

In this case I believe the initial steering was correct but the
velocity was far too slow - thus we are all frustrated.

    Brian

JORDI PALET MARTINEZ wrote:
> Hi Jonne,
> 
> I'm not upset about this specific issue, even if it seems so. I was upset
> long time ago on this ;-) We need to look in a positive way. What was done
> wrong, should be recognized, and not do the same error twice !
> 
> I know it was a decision (not the WG decision, and that's the problem !),
> and is to late to change it, but NOW, we have an opportunity to do better
> the next steps, at least with the WG agreement.
> 
> So please, start the discussion now in the list, provide inputs about what
> are your proposing, different alternatives, etc.
> 
> The meeting is never enough (even with time restrictions, people not there
> which may contribute, etc.), specially if the inputs aren't there up-front.
> 
> I think that should be a fair way to continue. Do you agree ?
> 
> Regards,
> Jordi
> 
> 
> 
>>De: "Soininen Jonne (Nokia-NET/Helsinki)" <jonne.soininen@nokia.com>
>>Responder a: owner-v6ops@ops.ietf.org
>>Fecha: Tue, 02 Nov 2004 17:35:43 +0200
>>Para: jordi.palet@consulintel.es
>>CC: v6ops@ops.ietf.org
>>Asunto: Re: WG process etc. [Re: WG last call on tunneling scenarios]
>>
>>Jordi,
>>
>>I see that you are upset. I'm sorry if you feel that there has not been
>>enough discussion on the topic.
>>
>>However, we have been working in the process where we have to finish the
>>scenarios/analysis to understand what we are supposed to do. This has
>>been in place from the start of v6ops. Maybe there has not been enough
>>discussion on this process, but I feel the discussion now is a bit late.
>>We are practically finished!
>>
>>I hope we can discuss the next steps now in full extent in the meeting
>>to make sure that nobody's voice goes unheard.
>>
>>Cheers,
>>
>>Jonne.
>>
>>
>>On Tue, 2004-11-02 at 03:08, ext JORDI PALET MARTINEZ wrote:
>>
>>>Hi Jonne,
>>>
>>>Well, as you know, I think this serial-mode has been wrong all the time. At
>>>least a "pure-serial" mode.
>>>
>>>I don't recall the WG being asked for doing this or not, just forced to.
>>>
>>>Is that an open process ?
>>>
>>>:-(
>>>
>>>Regards,
>>>Jordi
>>>
>>>
>>>
>>>>De: "Soininen Jonne (Nokia-NET/Helsinki)" <jonne.soininen@nokia.com>
>>>>Responder a: owner-v6ops@ops.ietf.org
>>>>Fecha: Tue, 02 Nov 2004 00:36:28 +0200
>>>>Para: "ext Bound, Jim" <jim.bound@hp.com>
>>>>CC: jordi.palet@consulintel.es, v6ops@ops.ietf.org
>>>>Asunto: RE: WG process etc. [Re: WG last call on tunneling scenarios]
>>>>
>>>>Ladies, and Gentlemen of the v6ops WG,
>>>>
>>>>I understand that the slow process of our little WG causes some
>>>>frustration among the participants of the WG.
>>>>
>>>>Like you all know, we have had this scenarios/analysis project going on
>>>>for a long time. To facilitate the quickest possible ending of that
>>>>project we decided in the IETF#60 meeting to concentrate on finishing
>>>>just those tasks. This has practically meant that much of the work has
>>>>concentrated on the remaining analysis document, and the now three
>>>>requirements documents.
>>>>
>>>>Basically the plan was the following:
>>>>
>>>>1) Finish the remaining analysis documents
>>>>2) Stabilize the requirements documents
>>>>3) Map the requirements to solutions
>>>>4) Refocus v6ops / start possibly needed work in the Internet Area
>>>>
>>>>I think we are somewhere between steps 2 and 3, right?
>>>>
>>>>I understand that people are anxious to start working on the actual
>>>>protocols - and believe me - I hope we could have started on the
>>>>technical work much earlier! However, sadly we just haven't gotten to
>>>>that point.
>>>>
>>>>It is obvious that we have not communicated enough where are we going
>>>>and to some of you this has been an indication of us doing things behind
>>>>your backs. We'll try to behave better in the future. However, you
>>>>shouldn't worry at least Pekka and I plotting behind your backs - we
>>>>agree on so few things, it wouldn't be even possible! ;)
>>>>
>>>>Cheers,
>>>>
>>>>Jonne.
>>>>
>>>>On Mon, 2004-11-01 at 22:28, ext Bound, Jim wrote:
>>>>
>>>>>Jordi,
>>>>>
>>>>>
>>>>>>On the other way around, I perfectly understand that industry is
>>>>>
>>>>>leading and some non-standards are
>>>>>
>>>>>>becoming de facto standards, which is not good.
>>>>>>That's why we need to work faster and in parallel instead of in serial
>>>>>
>>>>>and slow mode. If the WG is not
>>>>>
>>>>>>commenting or providing inputs, but there are no objections either, the
>>>>>
>>>>>work should be standardized.
>>>>>
>>>>>This is your confusion and the IETF changed I think about 18 months ago
>>>>>or when we killed A6.  Specs cannot go forward from silence and that is
>>>>>now true in all IETF WGs I know of in the IETF.  I first ran into this
>>>>>in DHCPv6 working with Ralph as Chair many years ago.  I did not like it
>>>>>at first and did not get it.  Then we were able to get the engineers to
>>>>>comment on DHCPv6 and made the spec 10 times as strong and solid
>>>>>consensus.  So now I am a firm believer in silence is no good as metric
>>>>>to move a spec forward.  Zero conf work had lots of mail thread
>>>>>discussions and appears to be valid to accept as work item within the
>>>>>IETF.  Bottom line is the Chairs have not broken any rule but enforcing
>>>>>the rule.  Also sometimes the WG is just maxed.  For example we did not
>>>>>get input as fast as we needed it for Enterprise Analysis but then we go
>>>>>so much I am still parsing it as Ent Analysis editor.  I don't think
>>>>>there is any scientific method to this at all the longer I am around.
>>>>>
>>>>>There is also no secret discussions that is just absurd.  Is it possible
>>>>>the ADs and Chairs individually don't support specific work, sure, but
>>>>>that's another matter and their right, and fair too.  The objective is
>>>>>to get the WG excited technically about specific work, and that makes
>>>>>the Chairs and ADs get a buzz.
>>>>>
>>>>>Reqarding industry doing defacto standards.  Yes this is happening now
>>>>>with IPv6 Transition and several mechanisms are being deployed now that
>>>>>are way ahead of the IETF.  That will correct itself between the market
>>>>>and the IETF.  At times the market leads, but usually the IETF is in
>>>>>synch with the curve, but not on time. But, v6ops is doing everything it
>>>>>can to meet time-to-market and I for one applaud all of us here for that
>>>>>we are getting real work done and on time.  As you know I am very pro
>>>>>defacto standards and solutions when the IETF don't get it and a large
>>>>>number of implementers do. We just move forward in industry and keep
>>>>>sending data to this body called the IETF.  The IPv6 Forum is exactly
>>>>>from the IETF moving to slow and in 1999 implementors took matters into
>>>>>their own hands and now the IPv6 Forum is a world wide deployment body
>>>>>that clearly can support defacto standards and with task forces that are
>>>>>part of the IPv6 Forum across the planet.  That is what happens when any
>>>>>standards body is to slow and does not meet the needs of the market.
>>>>>
>>>>>I read every mail on this list and a few others and you have not been
>>>>>treated unfairly at all, but your work has not reached consenus on this
>>>>>list that I can see as working group items.  That does not mean it is
>>>>>not good work but maybe not work in the IETF, as a question?  Ask your
>>>>>self is it a protocol, operational tool that can be standard without
>>>>>forcing implementation of protocols through configuration, a best
>>>>>current practice, etc.?  And most important "what problem does your work
>>>>>solve"?  
>>>>>
>>>>>What I have found with my work in the IETF when it stalls it is usually
>>>>>there was no consensus on the problem it solves or there needs to first
>>>>>be discussion of everyones assumptions.  For example, I believe many
>>>>>customers will simply shut off IPv4 on a dual IPv4/IPv6 subnetwork and
>>>>>cascade that policy expediently as a transition strategy across all
>>>>>their other subnetworks until the entire customers Intranet or Internet
>>>>>is IPv6 dominant with only pockets of legacy IPv4 for transition.
>>>>>Educating all why and how is what I am doing now and once they see that
>>>>>then solving the problem can move forward.  I also think most customers
>>>>>now will go get IPv6 prefixes and 6to4 is highly questionable as widely
>>>>>used for the transition and that is a new change in the market some of
>>>>>us have learned directly.  These are just examples of others who have
>>>>>the same problem and I don't think it is because of secret meetings in
>>>>>the IETF.
>>>>>
>>>>>I don't think the chairs or ADs warrant your mail and its unfair as one
>>>>>working group members input these chairs work their ass off and do what
>>>>>they can to keep things moving.  Now if they don't listen or ignore
>>>>>consensus I will be the first to throw tomatoes, but I don't see that in
>>>>>this specific case.
>>>>>
>>>>>P.S. Pekka - I still do not agree with you about 70% of the time :--)
>>>>>
>>>>>Regards,
>>>>>/jim
>>>>>
>>>>>
>>>>
>>>>-- 
>>>>Jonne Soininen
>>>>Nokia
>>>>
>>>>Tel: +358 40 527 46 34
>>>>E-mail: jonne.soininen@nokia.com
>>>>
>>>>
>>>
>>>
>>>
>>>**********************************
>>>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.
>>>
>>>
>>
>>-- 
>>Jonne Soininen
>>Nokia
>>
>>Tel: +358 40 527 46 34
>>E-mail: jonne.soininen@nokia.com
>>
>>
> 
> 
> 
> 
> **********************************
> 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.
> 
> 
> 
> 



From owner-v6ops@ops.ietf.org  Wed Nov  3 05:59:20 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21478
	for <v6ops-archive@lists.ietf.org>; Wed, 3 Nov 2004 05:59:19 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CPIpm-0004vd-Bv
	for v6ops-data@psg.com; Wed, 03 Nov 2004 10:57:46 +0000
Received: from [213.172.48.142] (helo=consulintel.es)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CPIph-0004tr-Jw
	for v6ops@ops.ietf.org; Wed, 03 Nov 2004 10:57:42 +0000
Received: from [150.254.161.141] ([150.254.161.141])
	by consulintel.es (consulintel.es [127.0.0.1])
	(MDaemon.PRO.v7.2.0.R)
	with ESMTP id md50000549160.msg
	for <v6ops@ops.ietf.org>; Wed, 03 Nov 2004 12:03:04 +0100
User-Agent: Microsoft-Entourage/10.1.4.030702.0
Date: Wed, 03 Nov 2004 11:57:25 +0100
Subject: Re: WG process etc. [Re: WG last call on tunneling scenarios]
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: <v6ops@ops.ietf.org>
Message-ID: <BDAE7825.4D875%jordi.palet@consulintel.es>
In-Reply-To: <4188B28D.9070208@zurich.ibm.com>
Mime-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
X-Spam-Processed: consulintel.es, Wed, 03 Nov 2004 12:03:04 +0100
	(not processed: message from valid local sender)
X-MDRemoteIP: 150.254.161.141
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ops.ietf.org
Reply-To: jordi.palet@consulintel.es
X-MDAV-Processed: consulintel.es, Wed, 03 Nov 2004 12:03:09 +0100
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

Hi Brian,

In than sense is my fault also, because I didn't reviewed the charter,
unfortunately, but I'd some disagreement in several occasions when talking
with the chairs about if this or that work falls within the charter, and
instead of (if needed) clarifying the charter, just nothing happened.

Now I asked for starting a discussion about what are the options, in order
to ask the WG inputs before the meeting, and have a more profitable meeting.

Hopefully we see something about this, may be today ?

Regards,
Jordi


> De: Brian E Carpenter <brc@zurich.ibm.com>
> Organizaci=F3n: IBM
> Responder a: owner-v6ops@ops.ietf.org
> Fecha: Wed, 03 Nov 2004 11:27:25 +0100
> Para: jordi.palet@consulintel.es
> CC: v6ops@ops.ietf.org
> Asunto: Re: WG process etc. [Re: WG last call on tunneling scenarios]
>=20
> Jordi,
>=20
>> I know it was a decision (not the WG decision, and that's the problem !),
>=20
> I don't think that's the problem. Consider the job that the community
> asks the ADs (i.e. the Steering Group) to do: steer the IETF. That's why
> it's the IESG that approves WG charters. You can say that the IESG
> steered incorrectly, but you can't say that they aren't allowed to
> steer.
>=20
> That is why WG charters are sent out for review - and people generally
> don't comment on them, as far as I can see. When I was in the IAB,
> I always felt that reviewing (IAB) and approving (IESG) charters was
> the most important single activity of those committees.
>=20
> In this case I believe the initial steering was correct but the
> velocity was far too slow - thus we are all frustrated.
>=20
>   Brian
>=20
> JORDI PALET MARTINEZ wrote:
>> Hi Jonne,
>>=20
>> I'm not upset about this specific issue, even if it seems so. I was upset
>> long time ago on this ;-) We need to look in a positive way. What was done
>> wrong, should be recognized, and not do the same error twice !
>>=20
>> I know it was a decision (not the WG decision, and that's the problem !),
>> and is to late to change it, but NOW, we have an opportunity to do better
>> the next steps, at least with the WG agreement.
>>=20
>> So please, start the discussion now in the list, provide inputs about what
>> are your proposing, different alternatives, etc.
>>=20
>> The meeting is never enough (even with time restrictions, people not there
>> which may contribute, etc.), specially if the inputs aren't there up-front.
>>=20
>> I think that should be a fair way to continue. Do you agree ?
>>=20
>> Regards,
>> Jordi
>>=20
>>=20
>>=20
>>> De: "Soininen Jonne (Nokia-NET/Helsinki)" <jonne.soininen@nokia.com>
>>> Responder a: owner-v6ops@ops.ietf.org
>>> Fecha: Tue, 02 Nov 2004 17:35:43 +0200
>>> Para: jordi.palet@consulintel.es
>>> CC: v6ops@ops.ietf.org
>>> Asunto: Re: WG process etc. [Re: WG last call on tunneling scenarios]
>>>=20
>>> Jordi,
>>>=20
>>> I see that you are upset. I'm sorry if you feel that there has not been
>>> enough discussion on the topic.
>>>=20
>>> However, we have been working in the process where we have to finish the
>>> scenarios/analysis to understand what we are supposed to do. This has
>>> been in place from the start of v6ops. Maybe there has not been enough
>>> discussion on this process, but I feel the discussion now is a bit late.
>>> We are practically finished!
>>>=20
>>> I hope we can discuss the next steps now in full extent in the meeting
>>> to make sure that nobody's voice goes unheard.
>>>=20
>>> Cheers,
>>>=20
>>> Jonne.
>>>=20
>>>=20
>>> On Tue, 2004-11-02 at 03:08, ext JORDI PALET MARTINEZ wrote:
>>>=20
>>>> Hi Jonne,
>>>>=20
>>>> Well, as you know, I think this serial-mode has been wrong all the time. At
>>>> least a "pure-serial" mode.
>>>>=20
>>>> I don't recall the WG being asked for doing this or not, just forced to.
>>>>=20
>>>> Is that an open process ?
>>>>=20
>>>> :-(
>>>>=20
>>>> Regards,
>>>> Jordi
>>>>=20
>>>>=20
>>>>=20
>>>>> De: "Soininen Jonne (Nokia-NET/Helsinki)" <jonne.soininen@nokia.com>
>>>>> Responder a: owner-v6ops@ops.ietf.org
>>>>> Fecha: Tue, 02 Nov 2004 00:36:28 +0200
>>>>> Para: "ext Bound, Jim" <jim.bound@hp.com>
>>>>> CC: jordi.palet@consulintel.es, v6ops@ops.ietf.org
>>>>> Asunto: RE: WG process etc. [Re: WG last call on tunneling scenarios]
>>>>>=20
>>>>> Ladies, and Gentlemen of the v6ops WG,
>>>>>=20
>>>>> I understand that the slow process of our little WG causes some
>>>>> frustration among the participants of the WG.
>>>>>=20
>>>>> Like you all know, we have had this scenarios/analysis project going on
>>>>> for a long time. To facilitate the quickest possible ending of that
>>>>> project we decided in the IETF#60 meeting to concentrate on finishing
>>>>> just those tasks. This has practically meant that much of the work has
>>>>> concentrated on the remaining analysis document, and the now three
>>>>> requirements documents.
>>>>>=20
>>>>> Basically the plan was the following:
>>>>>=20
>>>>> 1) Finish the remaining analysis documents
>>>>> 2) Stabilize the requirements documents
>>>>> 3) Map the requirements to solutions
>>>>> 4) Refocus v6ops / start possibly needed work in the Internet Area
>>>>>=20
>>>>> I think we are somewhere between steps 2 and 3, right?
>>>>>=20
>>>>> I understand that people are anxious to start working on the actual
>>>>> protocols - and believe me - I hope we could have started on the
>>>>> technical work much earlier! However, sadly we just haven't gotten to
>>>>> that point.
>>>>>=20
>>>>> It is obvious that we have not communicated enough where are we going
>>>>> and to some of you this has been an indication of us doing things behind
>>>>> your backs. We'll try to behave better in the future. However, you
>>>>> shouldn't worry at least Pekka and I plotting behind your backs - we
>>>>> agree on so few things, it wouldn't be even possible! ;)
>>>>>=20
>>>>> Cheers,
>>>>>=20
>>>>> Jonne.
>>>>>=20
>>>>> On Mon, 2004-11-01 at 22:28, ext Bound, Jim wrote:
>>>>>=20
>>>>>> Jordi,
>>>>>>=20
>>>>>>=20
>>>>>>> On the other way around, I perfectly understand that industry is
>>>>>>=20
>>>>>> leading and some non-standards are
>>>>>>=20
>>>>>>> becoming de facto standards, which is not good.
>>>>>>> That's why we need to work faster and in parallel instead of in serial
>>>>>>=20
>>>>>> and slow mode. If the WG is not
>>>>>>=20
>>>>>>> commenting or providing inputs, but there are no objections either, the
>>>>>>=20
>>>>>> work should be standardized.
>>>>>>=20
>>>>>> This is your confusion and the IETF changed I think about 18 months ago
>>>>>> or when we killed A6.  Specs cannot go forward from silence and that is
>>>>>> now true in all IETF WGs I know of in the IETF.  I first ran into this
>>>>>> in DHCPv6 working with Ralph as Chair many years ago.  I did not like it
>>>>>> at first and did not get it.  Then we were able to get the engineers to
>>>>>> comment on DHCPv6 and made the spec 10 times as strong and solid
>>>>>> consensus.  So now I am a firm believer in silence is no good as metric
>>>>>> to move a spec forward.  Zero conf work had lots of mail thread
>>>>>> discussions and appears to be valid to accept as work item within the
>>>>>> IETF.  Bottom line is the Chairs have not broken any rule but enforcing
>>>>>> the rule.  Also sometimes the WG is just maxed.  For example we did not
>>>>>> get input as fast as we needed it for Enterprise Analysis but then we go
>>>>>> so much I am still parsing it as Ent Analysis editor.  I don't think
>>>>>> there is any scientific method to this at all the longer I am around.
>>>>>>=20
>>>>>> There is also no secret discussions that is just absurd.  Is it possible
>>>>>> the ADs and Chairs individually don't support specific work, sure, but
>>>>>> that's another matter and their right, and fair too.  The objective is
>>>>>> to get the WG excited technically about specific work, and that makes
>>>>>> the Chairs and ADs get a buzz.
>>>>>>=20
>>>>>> Reqarding industry doing defacto standards.  Yes this is happening now
>>>>>> with IPv6 Transition and several mechanisms are being deployed now that
>>>>>> are way ahead of the IETF.  That will correct itself between the market
>>>>>> and the IETF.  At times the market leads, but usually the IETF is in
>>>>>> synch with the curve, but not on time. But, v6ops is doing everything it
>>>>>> can to meet time-to-market and I for one applaud all of us here for that
>>>>>> we are getting real work done and on time.  As you know I am very pro
>>>>>> defacto standards and solutions when the IETF don't get it and a large
>>>>>> number of implementers do. We just move forward in industry and keep
>>>>>> sending data to this body called the IETF.  The IPv6 Forum is exactly
>>>>>> from the IETF moving to slow and in 1999 implementors took matters into
>>>>>> their own hands and now the IPv6 Forum is a world wide deployment body
>>>>>> that clearly can support defacto standards and with task forces that are
>>>>>> part of the IPv6 Forum across the planet.  That is what happens when any
>>>>>> standards body is to slow and does not meet the needs of the market.
>>>>>>=20
>>>>>> I read every mail on this list and a few others and you have not been
>>>>>> treated unfairly at all, but your work has not reached consenus on this
>>>>>> list that I can see as working group items.  That does not mean it is
>>>>>> not good work but maybe not work in the IETF, as a question?  Ask your
>>>>>> self is it a protocol, operational tool that can be standard without
>>>>>> forcing implementation of protocols through configuration, a best
>>>>>> current practice, etc.?  And most important "what problem does your work
>>>>>> solve"? =20
>>>>>>=20
>>>>>> What I have found with my work in the IETF when it stalls it is usually
>>>>>> there was no consensus on the problem it solves or there needs to first
>>>>>> be discussion of everyones assumptions.  For example, I believe many
>>>>>> customers will simply shut off IPv4 on a dual IPv4/IPv6 subnetwork and
>>>>>> cascade that policy expediently as a transition strategy across all
>>>>>> their other subnetworks until the entire customers Intranet or Internet
>>>>>> is IPv6 dominant with only pockets of legacy IPv4 for transition.
>>>>>> Educating all why and how is what I am doing now and once they see that
>>>>>> then solving the problem can move forward.  I also think most customers
>>>>>> now will go get IPv6 prefixes and 6to4 is highly questionable as widely
>>>>>> used for the transition and that is a new change in the market some of
>>>>>> us have learned directly.  These are just examples of others who have
>>>>>> the same problem and I don't think it is because of secret meetings in
>>>>>> the IETF.
>>>>>>=20
>>>>>> I don't think the chairs or ADs warrant your mail and its unfair as one
>>>>>> working group members input these chairs work their ass off and do what
>>>>>> they can to keep things moving.  Now if they don't listen or ignore
>>>>>> consensus I will be the first to throw tomatoes, but I don't see that in
>>>>>> this specific case.
>>>>>>=20
>>>>>> P.S. Pekka - I still do not agree with you about 70% of the time :--)
>>>>>>=20
>>>>>> Regards,
>>>>>> /jim
>>>>>>=20
>>>>>>=20
>>>>>=20
>>>>> --=20
>>>>> Jonne Soininen
>>>>> Nokia
>>>>>=20
>>>>> Tel: +358 40 527 46 34
>>>>> E-mail: jonne.soininen@nokia.com
>>>>>=20
>>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>> **********************************
>>>> Madrid 2003 Global IPv6 Summit
>>>> Presentations and videos on line at:
>>>> http://www.ipv6-es.com
>>>>=20
>>>> 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.
>>>>=20
>>>>=20
>>>=20
>>> --=20
>>> Jonne Soininen
>>> Nokia
>>>=20
>>> Tel: +358 40 527 46 34
>>> E-mail: jonne.soininen@nokia.com
>>>=20
>>>=20
>>=20
>>=20
>>=20
>>=20
>> **********************************
>> Madrid 2003 Global IPv6 Summit
>> Presentations and videos on line at:
>> http://www.ipv6-es.com
>>=20
>> 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.
>>=20
>>=20
>>=20
>>=20
>=20
>=20



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






From owner-v6ops@ops.ietf.org  Wed Nov  3 06:19:35 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24487
	for <v6ops-archive@lists.ietf.org>; Wed, 3 Nov 2004 06:19:35 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CPJA2-0008Tg-I7
	for v6ops-data@psg.com; Wed, 03 Nov 2004 11:18:42 +0000
Received: from [203.253.3.140] (helo=cns.ssu.ac.kr)
	by psg.com with smtp (Exim 4.41 (FreeBSD))
	id 1CPJ9v-0008ST-6O
	for v6ops@ops.ietf.org; Wed, 03 Nov 2004 11:18:35 +0000
Received: from cnsljjang (203.253.3.137)
	by cns.ssu.ac.kr (203.253.3.140) with [Nmail V3.2 20020608(S)]
	for <v6ops@ops.ietf.org> from <ischl@cns.ssu.ac.kr>;
	Wed, 03 Nov 2004 20:24:41 +0900
From: "Inseok Choi" <ischl@cns.ssu.ac.kr>
To: <Francis.Dupont@enst-bretagne.fr>
Cc: <v6ops@ops.ietf.org>
Subject: RE: IPsec support for NAT-PT in IPv6 
Date: Wed, 3 Nov 2004 20:18:33 +0900
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-reply-to: <200411021320.iA2DKFSj059105@givry.rennes.enst-bretagne.fr>
Thread-Index: AcTA35VmOuCRhDWRQ/eeU2FSCD5qYQAAEYsw
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Message-Id: <E1CPJA2-0008Tg-I7@psg.com>
Content-Transfer-Encoding: 7bit

* IKE ==> In environment which it use dynamic address(DHCP, NAT, ...), as
possible as we use IKE using CERT. but IKE can't surely use CERT in
condition (ex> no CERT, authentication of IP address).
In real IKE procedure, I think we need to see things from various
methodology.

* IPsec using UDP encapsulation in NAT-PT
==> If we use IPsec using UDP encapsulation, see below
1. NAT ==> |New IPv4 header|UDP|Original IPv4 header|IKE or AH payload|
2. NAT-PT ==> |New IPv4 header|UDP|Original IPv6 header|IKE of AH payload|

NAT can use UDP encapsulation method because no change Original IPv4 header.
and opposite peer can understand original IPv4 packet.
But NAT-PT can't use same method because opposite peer can't understand
original IPv6 packet.

-----Original Message-----
From: Francis.Dupont@enst-bretagne.fr
[mailto:Francis.Dupont@enst-bretagne.fr] 
Sent: Tuesday, November 02, 2004 10:20 PM
To: Inseok Choi
Cc: v6ops@ops.ietf.org
Subject: Re: IPsec support for NAT-PT in IPv6 

 In your previous mail you wrote:

   in 2.1 ==> My proposed mechanism was assume IKE using preshared key
Phase.

=> preshared key with not predictable address doesn't work in main mode,
there is nothing to do to fix that because this is an intrinsic feature
(identity protection).

   If we can't IKE using use certificate, we should use IKE using other way.
   
   in IPsec using UDP encapsulation ==> NAT-PT can't apply to it.

=> why? UDP encapsulation is there to help header translation and is
not limited to NAT.

   If we use IPsec using UDP encapsulation in NAT-PT, NAT-PT server
   may send IPv4-in-IPv6 packet.

=> I can't see the problem: the user wants to protect and encapsulate
its IPv6 packet...

   However IPv4 node don't understand IPv6 packet.
   
=> so tunnel mode is not usable but transport is.

   Therefore, NAT traversal method can be applied to NAT-PT mechanism.
   
Regards
   
Francis.Dupont@enst-bretagne.fr




From owner-v6ops@ops.ietf.org  Wed Nov  3 12:27:28 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29727
	for <v6ops-archive@lists.ietf.org>; Wed, 3 Nov 2004 12:27:27 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CPOt2-000ATW-KD
	for v6ops-data@psg.com; Wed, 03 Nov 2004 17:25:32 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CPOsy-000ASs-4L
	for v6ops@ops.ietf.org; Wed, 03 Nov 2004 17:25:28 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id iA3HPMN19720
	for <v6ops@ops.ietf.org>; Wed, 3 Nov 2004 19:25:22 +0200
Date: Wed, 3 Nov 2004 19:25:21 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: v6ops@ops.ietf.org
Subject: Re: WG last call on tunneling scenarios
In-Reply-To: <Pine.LNX.4.61.0410300932370.7022@netcore.fi>
Message-ID: <Pine.LNX.4.61.0411031922180.19604@netcore.fi>
References: <Pine.LNX.4.61.0410291149220.9900@netcore.fi> <20041030040506.GA3476@nokia.com>
 <Pine.LNX.4.61.0410300932370.7022@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

Hi,

On Sat, 30 Oct 2004, Pekka Savola wrote:
> Fair enough.  Please send the objections (if any) on document 
> adoption by the end of Tuesday 2nd November at the latest.
>
> Comments/review on the drafts themselves are still welcome!

(hat on)

As there were no specific objections to adopting these documents, 
there appears to be rough consensus on taking these as WG items.

Let's continue the WG last call as called out earlier.

*** We really need the reviews, and that means *YOU* too! :) ***

(hat off)



From owner-v6ops@ops.ietf.org  Wed Nov  3 14:54:51 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13237
	for <v6ops-archive@lists.ietf.org>; Wed, 3 Nov 2004 14:54:50 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CPRBk-0007F1-7T
	for v6ops-data@psg.com; Wed, 03 Nov 2004 19:53:00 +0000
Received: from [213.172.48.142] (helo=consulintel.es)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CPRBj-0007Ef-60
	for v6ops@ops.ietf.org; Wed, 03 Nov 2004 19:52:59 +0000
Received: from [192.168.0.101] ([150.254.185.155])
	by consulintel.es (consulintel.es [127.0.0.1])
	(MDaemon.PRO.v7.2.0.R)
	with ESMTP id md50000553482.msg
	for <v6ops@ops.ietf.org>; Wed, 03 Nov 2004 20:58:24 +0100
User-Agent: Microsoft-Entourage/10.1.4.030702.0
Date: Wed, 03 Nov 2004 20:51:27 +0100
Subject: Re: WG last call on tunneling scenarios
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: <v6ops@ops.ietf.org>
Message-ID: <BDAEF54F.4DB38%jordi.palet@consulintel.es>
In-Reply-To: <Pine.LNX.4.61.0411031922180.19604@netcore.fi>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Spam-Processed: consulintel.es, Wed, 03 Nov 2004 20:58:24 +0100
	(not processed: message from valid local sender)
X-MDRemoteIP: 150.254.185.155
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ops.ietf.org
Reply-To: jordi.palet@consulintel.es
X-MDAV-Processed: consulintel.es, Wed, 03 Nov 2004 20:58:27 +0100
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Ok. So then we should be fair enough also with the rest of the documents and
ask the same question, and see if there is any objection.

Regards,
Jordi


> De: Pekka Savola <pekkas@netcore.fi>
> Responder a: owner-v6ops@ops.ietf.org
> Fecha: Wed, 3 Nov 2004 19:25:21 +0200 (EET)
> Para: v6ops@ops.ietf.org
> Asunto: Re: WG last call on tunneling scenarios
> 
> Hi,
> 
> On Sat, 30 Oct 2004, Pekka Savola wrote:
>> Fair enough.  Please send the objections (if any) on document
>> adoption by the end of Tuesday 2nd November at the latest.
>> 
>> Comments/review on the drafts themselves are still welcome!
> 
> (hat on)
> 
> As there were no specific objections to adopting these documents,
> there appears to be rough consensus on taking these as WG items.
> 
> Let's continue the WG last call as called out earlier.
> 
> *** We really need the reviews, and that means *YOU* too! :) ***
> 
> (hat off)
> 
> 



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






From owner-v6ops@ops.ietf.org  Wed Nov  3 15:07:20 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14598
	for <v6ops-archive@lists.ietf.org>; Wed, 3 Nov 2004 15:07:19 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CPRP9-0009cv-JH
	for v6ops-data@psg.com; Wed, 03 Nov 2004 20:06:51 +0000
Received: from [213.172.48.142] (helo=consulintel.es)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CPRP8-0009cN-Ib
	for v6ops@ops.ietf.org; Wed, 03 Nov 2004 20:06:50 +0000
Received: from [192.168.0.101] ([150.254.185.155])
	by consulintel.es (consulintel.es [127.0.0.1])
	(MDaemon.PRO.v7.2.0.R)
	with ESMTP id md50000553650.msg
	for <v6ops@ops.ietf.org>; Wed, 03 Nov 2004 21:12:18 +0100
User-Agent: Microsoft-Entourage/10.1.4.030702.0
Date: Wed, 03 Nov 2004 21:00:47 +0100
Subject: Next steps
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: Pekka Savola <pekkas@netcore.fi>,
        "Soininen Jonne (Nokia-NET/Helsinki)" <jonne.soininen@nokia.com>
CC: <v6ops@ops.ietf.org>
Message-ID: <BDAEF77F.4DB4A%jordi.palet@consulintel.es>
Mime-version: 1.0
X-Priority: 1
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Spam-Processed: consulintel.es, Wed, 03 Nov 2004 21:12:18 +0100
	(not processed: message from valid local sender)
X-MDRemoteIP: 150.254.185.155
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ops.ietf.org
Reply-To: jordi.palet@consulintel.es
X-MDAV-Processed: consulintel.es, Wed, 03 Nov 2004 21:12:19 +0100
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-3.6 required=5.0 tests=AWL,BAYES_00,PRIORITY_NO_NAME,
	X_PRIORITY_HIGH autolearn=no version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Jonne, Pekka,

I've requested, several times, in the last couple of days, to get the
information about any proposal that you have for the WG.

I will much prefer if you can provide any inputs, and we all discuss about
it.

No reply means to me that you don't have any proposal (as nothing should be
secret and openly discussed as you already indicated !), so anyone with some
ideas should start it, otherwise, we are missing precious time in the next
meeting.

Please, let me know urgently.

Regards,
Jordi




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






From owner-v6ops@ops.ietf.org  Wed Nov  3 15:35:23 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17486
	for <v6ops-archive@lists.ietf.org>; Wed, 3 Nov 2004 15:35:23 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CPRpv-000Df4-6g
	for v6ops-data@psg.com; Wed, 03 Nov 2004 20:34:31 +0000
Received: from [207.31.248.245] (helo=thingmagic.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CPRpu-000Deg-C9
	for v6ops@ops.ietf.org; Wed, 03 Nov 2004 20:34:30 +0000
Received: from [10.0.0.75] (account margaret HELO [192.168.2.2])
  by thingmagic.com (CommuniGate Pro SMTP 4.1.8)
  with ESMTP-TLS id 185851; Wed, 03 Nov 2004 15:28:35 -0500
Mime-Version: 1.0
X-Sender: margaret@mail.thingmagic.com
Message-Id: <p0602046dbdaeefd531a9@[192.168.2.2]>
In-Reply-To: <BDAEF77F.4DB4A%jordi.palet@consulintel.es>
References: <BDAEF77F.4DB4A%jordi.palet@consulintel.es>
X-Priority: 1 (Highest)
Date: Wed, 3 Nov 2004 15:33:15 -0500
To: jordi.palet@consulintel.es, Pekka Savola <pekkas@netcore.fi>,
        "Soininen Jonne (Nokia-NET/Helsinki)" <jonne.soininen@nokia.com>
From: Margaret Wasserman <margaret@thingmagic.com>
Subject: Re: Next steps
Cc: <v6ops@ops.ietf.org>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-3.5 required=5.0 tests=AWL,BAYES_00,PRIORITY_NO_NAME,
	X_PRIORITY_HIGH autolearn=no version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk


Okay, I'll bite!!!  :-)

Speaking only as an interested individual and long term ngtrans/v6ops 
participant...

I would like to see the v6ops finish up the scenario/analysis 
documents and start focusing on some of the important IPv6 
operational issues that should (IMO) be the province of this WG.

For instance, I think that we could do some valuable work studying 
the security implications of running a dual-stack enterprise network 
and documenting some operational best practices for that type of 
deployment.

I'd also like to see us engage some the early IPv6 ISP-type operators 
(Japanese ISPs, the 6Net folks, Internet 2, etc.) and discuss their 
experiences, particularly an operational problems that they have 
experienced.

Margaret


At 9:00 PM +0100 11/3/04, JORDI PALET MARTINEZ wrote:
>Hi Jonne, Pekka,
>
>I've requested, several times, in the last couple of days, to get the
>information about any proposal that you have for the WG.
>
>I will much prefer if you can provide any inputs, and we all discuss about
>it.
>
>No reply means to me that you don't have any proposal (as nothing should be
>secret and openly discussed as you already indicated !), so anyone with some
>ideas should start it, otherwise, we are missing precious time in the next
>meeting.
>
>Please, let me know urgently.
>
>Regards,
>Jordi
>
>
>
>
>**********************************
>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.




From owner-v6ops@ops.ietf.org  Wed Nov  3 15:45:33 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18326
	for <v6ops-archive@lists.ietf.org>; Wed, 3 Nov 2004 15:45:33 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CPS0E-000FLB-Nd
	for v6ops-data@psg.com; Wed, 03 Nov 2004 20:45:10 +0000
Received: from [131.228.20.21] (helo=mgw-x1.nokia.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CPS0D-000FKv-IK
	for v6ops@ops.ietf.org; Wed, 03 Nov 2004 20:45:09 +0000
Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120])
	by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA3Kj6322331;
	Wed, 3 Nov 2004 22:45:07 +0200 (EET)
X-Scanned: Wed, 3 Nov 2004 22:44:48 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE
Received: (from root@localhost)
	by esdks001.ntc.nokia.com (8.12.9/8.12.9) id iA3KimrF028635;
	Wed, 3 Nov 2004 22:44:48 +0200
Received: from mgw-int2.ntc.nokia.com (172.21.143.97)
	by esdks001.ntc.nokia.com 00WmMtpQ; Wed, 03 Nov 2004 22:44:46 EET
Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84])
	by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA3Ki6S26067;
	Wed, 3 Nov 2004 22:44:06 +0200 (EET)
Received: from esebe009.NOE.Nokia.com ([172.21.138.41]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881);
	 Wed, 3 Nov 2004 22:44:05 +0200
Received: from esebe054.NOE.Nokia.com ([172.21.143.44]) by esebe009.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881);
	 Wed, 3 Nov 2004 22:44:04 +0200
Received: ESEBE054.noe.nokia.com 172.21.143.44 from 10.162.253.64 10.162.253.64 via HTTP with MS-WebStorage 6.0.6249
Received: from localhost.localdomain by ESEBE054.noe.nokia.com; 03 Nov 2004 22:44:05 +0200
Subject: Re: Next steps
From: "Soininen Jonne (Nokia-NET/Helsinki)" <jonne.soininen@nokia.com>
To: ext Margaret Wasserman <margaret@thingmagic.com>
Cc: jordi.palet@consulintel.es, ext Pekka Savola <pekkas@netcore.fi>,
        v6ops@ops.ietf.org
In-Reply-To: <p0602046dbdaeefd531a9@[192.168.2.2]>
References: <BDAEF77F.4DB4A%jordi.palet@consulintel.es>
	 <p0602046dbdaeefd531a9@[192.168.2.2]>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1099514645.4406.25.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.6 
Date: Wed, 03 Nov 2004 22:44:05 +0200
X-OriginalArrivalTime: 03 Nov 2004 20:44:04.0976 (UTC) FILETIME=[DBA2AF00:01C4C1E5]
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Everybody,

I agree with Margaret and I think this has been mainly in line with the
direction of the WG: I believe we should finish the scenarios/analysis
work ASAP and if there is need to do specification work, move the work
to the Internet area. V6ops should refocus on the actual operational
issues.

Cheers,

Jonne.

On Wed, 2004-11-03 at 22:33, ext Margaret Wasserman wrote:
> Okay, I'll bite!!!  :-)
> 
> Speaking only as an interested individual and long term ngtrans/v6ops 
> participant...
> 
> I would like to see the v6ops finish up the scenario/analysis 
> documents and start focusing on some of the important IPv6 
> operational issues that should (IMO) be the province of this WG.
> 
> For instance, I think that we could do some valuable work studying 
> the security implications of running a dual-stack enterprise network 
> and documenting some operational best practices for that type of 
> deployment.
> 
> I'd also like to see us engage some the early IPv6 ISP-type operators 
> (Japanese ISPs, the 6Net folks, Internet 2, etc.) and discuss their 
> experiences, particularly an operational problems that they have 
> experienced.
> 
> Margaret
> 
> 
> At 9:00 PM +0100 11/3/04, JORDI PALET MARTINEZ wrote:
> >Hi Jonne, Pekka,
> >
> >I've requested, several times, in the last couple of days, to get the
> >information about any proposal that you have for the WG.
> >
> >I will much prefer if you can provide any inputs, and we all discuss about
> >it.
> >
> >No reply means to me that you don't have any proposal (as nothing should be
> >secret and openly discussed as you already indicated !), so anyone with some
> >ideas should start it, otherwise, we are missing precious time in the next
> >meeting.
> >
> >Please, let me know urgently.
> >
> >Regards,
> >Jordi
> >
> >
> >
> >
> >**********************************
> >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.
-- 
Jonne Soininen
Nokia

Tel: +358 40 527 46 34
E-mail: jonne.soininen@nokia.com



From owner-v6ops@ops.ietf.org  Wed Nov  3 18:18:42 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02150
	for <v6ops-archive@lists.ietf.org>; Wed, 3 Nov 2004 18:18:41 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CPUNK-000EFl-Ea
	for v6ops-data@psg.com; Wed, 03 Nov 2004 23:17:10 +0000
Received: from [213.172.48.142] (helo=consulintel.es)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CPUNJ-000EFK-0N
	for v6ops@ops.ietf.org; Wed, 03 Nov 2004 23:17:09 +0000
Received: from [192.168.0.101] ([150.254.185.155])
	by consulintel.es (consulintel.es [127.0.0.1])
	(MDaemon.PRO.v7.2.0.R)
	with ESMTP id md50000554115.msg
	for <v6ops@ops.ietf.org>; Thu, 04 Nov 2004 00:22:31 +0100
User-Agent: Microsoft-Entourage/10.1.4.030702.0
Date: Thu, 04 Nov 2004 00:01:24 +0100
Subject: Re: Next steps
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: <v6ops@ops.ietf.org>
Message-ID: <BDAF21D4.4DBB2%jordi.palet@consulintel.es>
In-Reply-To: <p0602046dbdaeefd531a9@[192.168.2.2]>
Mime-version: 1.0
X-Priority: 1
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Spam-Processed: consulintel.es, Thu, 04 Nov 2004 00:22:31 +0100
	(not processed: message from valid local sender)
X-MDRemoteIP: 150.254.185.155
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ops.ietf.org
Reply-To: jordi.palet@consulintel.es
X-MDAV-Processed: consulintel.es, Thu, 04 Nov 2004 00:22:36 +0100
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-3.4 required=5.0 tests=AWL,BAYES_00,PRIORITY_NO_NAME,
	X_PRIORITY_HIGH autolearn=no version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Margaret,

Agree with your comments (for example your point about security is section 4
of the charter), in general, but reading the charter I still don't think
there is any place where is said that we should have proceed in serial-mode.
Should we appeal that decision ? May be I'm wrong, so somebody can provide a
prove that this has been approved by the WG ?

Same with the rationale being followed to decide (by the WG) that no more
documents are accepted as WG items, and then some are now accepted and not
some others. Again, appeal ?

By the way, we the "Euro6IX" folks (including the 8 bigger European Telcos),
have proposed several documents, including operational security implications
of IPv6. This is fully within the charter, and is being ignored as a WG
item. Again, should we appeal ?

Also the same folks proposed some works regarding operational transition
issues, like the auto-discovery of the TEP. This work was even backed-up by
the request of the chairs. Still not even suggested to be WG item, so I ask
now for it. If nobody objects in 2 days, as has been done with the other
documents, clearly is accepted. Right ? Fair enough ?

Now, looking at the charter
(http://www.ietf.org/html.charters/v6ops-charter.html):

1. Solicit input from network operators and users to identify
  operational or security issues with the IPv4/IPv6 Internet, and
  determine solutions or workarounds to those issues.  This includes
  identifying standards work that is needed in other IETF WGs or
  areas and working with those groups/areas to begin appropriate
  work.  These issues will be documented in Informational or BCP
  RFCs, or in Internet-Drafts.

-> Some (not to say all) of the stalled work (the one not being accepted as
WG item), is within this section. This is clearly the case for the
transitions related documents and also for those related to security.

-> Furthermore, the same is supported by:

6. Identify open operational or security issues with the deployment
  scenarios documented in (5) and fully document those open
  issues in Internet-Drafts or Informational RFCs.  Work to find
  workarounds or solutions to basic, IP-level operational
  or security issues that can be solved using widely-applicable
  transition mechanisms, such as dual-stack, tunneling or
  translation.


-> Now can tell me, where it says something about the serial-mode ? If not,
please demonstrate that the decision is done by the WG and is fair. Same for
why only a few documents are being proposed as WG items ?

So in my opinion, what we should do (in PARALLEL mode whenever possible):

1) Correct the previous mistakes with decisions that aren't backed up by the
WG, even appeal them if required (this includes serial-mode work and unfair
acceptance of WG items).

2) Continue with the scenarios/analysis.

3) Continue with the operational issues regarding facilitating the
transition. Some already identified and with live documents. Others may need
new work. Do we have the adequate transition mechanisms to cover all the
scenario/analysis ?, what about 6in6, 6in4, 6inudp, others ? What about the
solutions (protocols, new/existing, changes to existing) for zeroconf in
3GPP, or in other networks ?

4) Continue with the operational issues regarding IPv6 security
implications, of both only IPv6 and IPv4/IPv6 networks. This may still need
some more work, some new documents, etc., as those existing may be not
enough.

5) Continue with whatever other operational issues may be required to work
on. Somebody can point out to some specific issues here ?

6) Is the applications work completed (not an expert here). Somebody feel
something else is missing ?

7) Anything missing regarding DNS operation ? SMTP, SIP, other protocols ?

8) Should any of the operational issues fall into the scope of another area
or WG for developing a new standard ? Or are we just describing the issues
and providing guidelines of how existing protocols can solve it ?

We will need probably to define concrete milestones, I guess may need
re-chartering with the consensus of the WG. And if something is not clearly
defined in the actual WG charter (for example if the interpretation of the
charter is not the same for the WG, overall), then we also need to
re-charter.

My position is that if we made a mistake with the charter, and we ignored it
so much time, now, we can't reject work because that, unless there is a WG
general consensus and no objections.

Probably I'm missing a lot of extra issues, possibilities, and so on, so
let's hope the rest of the WG can speak up !

Regards,
Jordi


> De: Margaret Wasserman <margaret@thingmagic.com>
> Responder a: owner-v6ops@ops.ietf.org
> Fecha: Wed, 3 Nov 2004 15:33:15 -0500
> Para: jordi.palet@consulintel.es, Pekka Savola <pekkas@netcore.fi>, "Soininen
> Jonne (Nokia-NET/Helsinki)" <jonne.soininen@nokia.com>
> CC: <v6ops@ops.ietf.org>
> Asunto: Re: Next steps
> 
> 
> Okay, I'll bite!!!  :-)
> 
> Speaking only as an interested individual and long term ngtrans/v6ops
> participant...
> 
> I would like to see the v6ops finish up the scenario/analysis
> documents and start focusing on some of the important IPv6
> operational issues that should (IMO) be the province of this WG.
> 
> For instance, I think that we could do some valuable work studying
> the security implications of running a dual-stack enterprise network
> and documenting some operational best practices for that type of
> deployment.
> 
> I'd also like to see us engage some the early IPv6 ISP-type operators
> (Japanese ISPs, the 6Net folks, Internet 2, etc.) and discuss their
> experiences, particularly an operational problems that they have
> experienced.
> 
> Margaret
> 
> 
> At 9:00 PM +0100 11/3/04, JORDI PALET MARTINEZ wrote:
>> Hi Jonne, Pekka,
>> 
>> I've requested, several times, in the last couple of days, to get the
>> information about any proposal that you have for the WG.
>> 
>> I will much prefer if you can provide any inputs, and we all discuss about
>> it.
>> 
>> No reply means to me that you don't have any proposal (as nothing should be
>> secret and openly discussed as you already indicated !), so anyone with some
>> ideas should start it, otherwise, we are missing precious time in the next
>> meeting.
>> 
>> Please, let me know urgently.
>> 
>> Regards,
>> Jordi
>> 
>> 
>> 
>> 
>> **********************************
>> 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.
> 
> 
> 



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






From owner-v6ops@ops.ietf.org  Wed Nov  3 18:32:35 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03223
	for <v6ops-archive@lists.ietf.org>; Wed, 3 Nov 2004 18:32:34 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CPUbn-000GP3-KJ
	for v6ops-data@psg.com; Wed, 03 Nov 2004 23:32:07 +0000
Received: from [213.172.48.142] (helo=consulintel.es)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CPUbm-000GOi-1b
	for v6ops@ops.ietf.org; Wed, 03 Nov 2004 23:32:06 +0000
Received: from [192.168.0.101] ([150.254.185.155])
	by consulintel.es (consulintel.es [127.0.0.1])
	(MDaemon.PRO.v7.2.0.R)
	with ESMTP id md50000554152.msg
	for <v6ops@ops.ietf.org>; Thu, 04 Nov 2004 00:37:32 +0100
User-Agent: Microsoft-Entourage/10.1.4.030702.0
Date: Thu, 04 Nov 2004 00:01:14 +0100
Subject: Re: Next steps
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: <v6ops@ops.ietf.org>
Message-ID: <BDAF21CA.4DBB2%jordi.palet@consulintel.es>
In-Reply-To: <1099514645.4406.25.camel@localhost.localdomain>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Spam-Processed: consulintel.es, Thu, 04 Nov 2004 00:37:32 +0100
	(not processed: message from valid local sender)
X-MDRemoteIP: 150.254.185.155
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ops.ietf.org
Reply-To: jordi.palet@consulintel.es
X-MDAV-Processed: consulintel.es, Thu, 04 Nov 2004 00:37:34 +0100
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Well, what I expected is a document or at least an email explaining this:

Discussion of the way forward - 15 mins, Chairs/ADs
  - GOAL: discuss and get consensus on how to proceed from here

The AD indicated that he asked for this, so I guess we should have "some"
document that at a minimum introduce the topic, options, etc. !

Can we see it ? Just an email will make it. Otherwise, we may need to spend
the complete meeting understanding that before taking a decision ? Don't
tell us later "no more mic" ! It will not be fair, and sure will be
appealed, believe me.

Moreover, remember that some people may be not in the meeting room, and they
have the right to know about this. Explain it now, is the best way to get
their inputs.

Thanks in advance for doing so !

Regards,
Jordi


> De: "Soininen Jonne (Nokia-NET/Helsinki)" <jonne.soininen@nokia.com>
> Responder a: owner-v6ops@ops.ietf.org
> Fecha: Wed, 03 Nov 2004 22:44:05 +0200
> Para: ext Margaret Wasserman <margaret@thingmagic.com>
> CC: jordi.palet@consulintel.es, ext Pekka Savola <pekkas@netcore.fi>,
> v6ops@ops.ietf.org
> Asunto: Re: Next steps
> 
> Everybody,
> 
> I agree with Margaret and I think this has been mainly in line with the
> direction of the WG: I believe we should finish the scenarios/analysis
> work ASAP and if there is need to do specification work, move the work
> to the Internet area. V6ops should refocus on the actual operational
> issues.
> 
> Cheers,
> 
> Jonne.
> 
> On Wed, 2004-11-03 at 22:33, ext Margaret Wasserman wrote:
>> Okay, I'll bite!!!  :-)
>> 
>> Speaking only as an interested individual and long term ngtrans/v6ops
>> participant...
>> 
>> I would like to see the v6ops finish up the scenario/analysis
>> documents and start focusing on some of the important IPv6
>> operational issues that should (IMO) be the province of this WG.
>> 
>> For instance, I think that we could do some valuable work studying
>> the security implications of running a dual-stack enterprise network
>> and documenting some operational best practices for that type of
>> deployment.
>> 
>> I'd also like to see us engage some the early IPv6 ISP-type operators
>> (Japanese ISPs, the 6Net folks, Internet 2, etc.) and discuss their
>> experiences, particularly an operational problems that they have
>> experienced.
>> 
>> Margaret
>> 
>> 
>> At 9:00 PM +0100 11/3/04, JORDI PALET MARTINEZ wrote:
>>> Hi Jonne, Pekka,
>>> 
>>> I've requested, several times, in the last couple of days, to get the
>>> information about any proposal that you have for the WG.
>>> 
>>> I will much prefer if you can provide any inputs, and we all discuss about
>>> it.
>>> 
>>> No reply means to me that you don't have any proposal (as nothing should be
>>> secret and openly discussed as you already indicated !), so anyone with some
>>> ideas should start it, otherwise, we are missing precious time in the next
>>> meeting.
>>> 
>>> Please, let me know urgently.
>>> 
>>> Regards,
>>> Jordi
>>> 
>>> 
>>> 
>>> 
>>> **********************************
>>> 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.
> -- 
> Jonne Soininen
> Nokia
> 
> Tel: +358 40 527 46 34
> E-mail: jonne.soininen@nokia.com
> 
> 



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






From owner-v6ops@ops.ietf.org  Wed Nov  3 20:27:19 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10738
	for <v6ops-archive@lists.ietf.org>; Wed, 3 Nov 2004 20:27:19 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CPWNn-000AEq-10
	for v6ops-data@psg.com; Thu, 04 Nov 2004 01:25:47 +0000
Received: from [131.228.20.27] (helo=mgw-x4.nokia.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CPWNl-000AEb-RS
	for v6ops@ops.ietf.org; Thu, 04 Nov 2004 01:25:46 +0000
Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120])
	by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA41Pil29052;
	Thu, 4 Nov 2004 03:25:44 +0200 (EET)
X-Scanned: Thu, 4 Nov 2004 03:24:44 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE
Received: (from root@localhost)
	by esdks001.ntc.nokia.com (8.12.9/8.12.9) id iA41OiU5000506;
	Thu, 4 Nov 2004 03:24:44 +0200
Received: from mgw-int2.ntc.nokia.com (172.21.143.97)
	by esdks001.ntc.nokia.com 00fqrQUG; Thu, 04 Nov 2004 03:24:43 EET
Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121])
	by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA41O6S18100;
	Thu, 4 Nov 2004 03:24:06 +0200 (EET)
Received: from dadhcp-172019068136.americas.nokia.com ([172.19.68.140]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881);
	 Wed, 3 Nov 2004 19:24:05 -0600
Received: from dadhcp-172019068136.americas.nokia.com (localhost.localdomain [127.0.0.1])
	by dadhcp-172019068136.americas.nokia.com (8.12.8/8.12.8) with ESMTP id iA41O41H004637;
	Wed, 3 Nov 2004 17:24:05 -0800
Received: (from kessens@localhost)
	by dadhcp-172019068136.americas.nokia.com (8.12.8/8.12.8/Submit) id iA41O4oi004635;
	Wed, 3 Nov 2004 17:24:04 -0800
Date: Wed, 3 Nov 2004 17:24:04 -0800
From: David Kessens <david.kessens@nokia.com>
To: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
Cc: v6ops@ops.ietf.org
Subject: Re: Next steps
Message-ID: <20041104012404.GA4532@nokia.com>
References: <1099514645.4406.25.camel@localhost.localdomain> <BDAF21CA.4DBB2%jordi.palet@consulintel.es>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <BDAF21CA.4DBB2%jordi.palet@consulintel.es>
User-Agent: Mutt/1.4.1i
X-OriginalArrivalTime: 04 Nov 2004 01:24:05.0719 (UTC) FILETIME=[F9A89E70:01C4C20C]
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk


Jordi,

On Thu, Nov 04, 2004 at 12:01:14AM +0100, JORDI PALET MARTINEZ wrote:
> Well, what I expected is a document or at least an email explaining this:
> 
> Discussion of the way forward - 15 mins, Chairs/ADs
>   - GOAL: discuss and get consensus on how to proceed from here
> 
> The AD indicated that he asked for this, so I guess we should have "some"
> document that at a minimum introduce the topic, options, etc. !

I think I already explained this to you:

We would like to discuss how to proceed from where we are, now that
most of our major milestones are accomplished.

It is up to the community/working group to form a consensus view
onwhere we want to go from here.

Margaret & Jonne already gave their views. Not speaking as an AD, I
like an approach as proposed by Margaret and supported by Jonne.

Speaking as an AD, the part of the title of the agenda topic that says
'get consensus' was perhaps not the best choice of words. I would like
to use the time to bootstrap the discussion on what is next and get
some sense of the room for which directions make sense.

David Kessens
---



From owner-v6ops@ops.ietf.org  Wed Nov  3 21:48:24 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16795
	for <v6ops-archive@lists.ietf.org>; Wed, 3 Nov 2004 21:48:23 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CPXeR-000KJW-Nb
	for v6ops-data@psg.com; Thu, 04 Nov 2004 02:47:03 +0000
Received: from [204.127.202.64] (helo=sccrmhc13.comcast.net)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CPXeQ-000KJI-UO
	for v6ops@ops.ietf.org; Thu, 04 Nov 2004 02:47:03 +0000
Received: from dfnjgl21 (c-24-1-97-29.client.comcast.net[24.1.97.29])
          by comcast.net (sccrmhc13) with SMTP
          id <200411040247010160014t30e>
          (Authid: sdawkins@comcast.net);
          Thu, 4 Nov 2004 02:47:02 +0000
Message-ID: <086501c4c218$ab4d25a0$0200a8c0@DFNJGL21>
Reply-To: "Spencer Dawkins" <spencer@mcsr-labs.org>
From: "Spencer Dawkins" <spencer@mcsr-labs.org>
To: <v6ops@ops.ietf.org>
Cc: "Ralph Droms" <rdroms@cisco.com>
References: <4.3.2.7.2.20041102083325.02a45ee0@flask.cisco.com> <Pine.LNX.4.61.0411021540110.14885@netcore.fi>
Subject: Re: POLL: SPs' IPv6 (tunnel) deployment requirements (fwd)
Date: Wed, 3 Nov 2004 20:47:47 -0600
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-1";
	reply-type=response
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi, Pekka,

Thank you for sending this off to NANOG.

I applaud anything the Operations Area does to increase dialog with 
NANOG, and the nice people at the NANOG 31 IETF feedback BoF said they 
really were interested in talking to us, they just had no clue how to 
figure out what we are doing or who to give feedback to...

Spencer 





From owner-v6ops@ops.ietf.org  Wed Nov  3 22:53:53 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20509
	for <v6ops-archive@lists.ietf.org>; Wed, 3 Nov 2004 22:53:53 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CPYfQ-0001ac-Qq
	for v6ops-data@psg.com; Thu, 04 Nov 2004 03:52:08 +0000
Received: from [207.31.248.245] (helo=thingmagic.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CPYfQ-0001aE-0y
	for v6ops@ops.ietf.org; Thu, 04 Nov 2004 03:52:08 +0000
Received: from [10.0.0.75] (account margaret HELO [192.168.2.2])
  by thingmagic.com (CommuniGate Pro SMTP 4.1.8)
  with ESMTP-TLS id 186037; Wed, 03 Nov 2004 22:46:20 -0500
Mime-Version: 1.0
X-Sender: margaret@mail.thingmagic.com
Message-Id: <p06020476bdaf561ebd5f@[192.168.2.2]>
In-Reply-To: <BDAF21D4.4DBB2%jordi.palet@consulintel.es>
References: <BDAF21D4.4DBB2%jordi.palet@consulintel.es>
X-Priority: 1 (Highest)
Date: Wed, 3 Nov 2004 22:51:00 -0500
To: jordi.palet@consulintel.es, <v6ops@ops.ietf.org>
From: Margaret Wasserman <margaret@thingmagic.com>
Subject: Re: Next steps
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-3.4 required=5.0 tests=AWL,BAYES_00,PRIORITY_NO_NAME,
	X_PRIORITY_HIGH autolearn=no version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk


Hi Jordi,

At 12:01 AM +0100 11/4/04, JORDI PALET MARTINEZ wrote:
>Agree with your comments (for example your point about security is section 4
>of the charter), in general, but reading the charter I still don't think
>there is any place where is said that we should have proceed in serial-mode.

I wrote the original charter for this WG, and he intention at the 
time was not to proceed in serial mode.

We were supposed to work on the scenarios/analysis before continuing 
work on the coexistence/transition mechanisms, but the operational 
work was intended to happen in parallel.  At least during the time 
that I was chairing the group, we did get some ISP/operator feedback 
and do some work on operational work.  We also continued working on 
the documents that summarized v6 work needed in various areas, 
provided advice to several areas that did lead to some important work 
and published them.

However, it was always a challenge (before and after the ngtrans -> 
v6ops transition) to get this particular WG actively engaged in the 
work of the group.

I think that many of the efforts you have mentioned would be good 
efforts for this group to undertake.

Margaret





From owner-v6ops@ops.ietf.org  Thu Nov  4 01:39:39 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03584
	for <v6ops-archive@lists.ietf.org>; Thu, 4 Nov 2004 01:39:38 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CPbFM-000Jqo-5W
	for v6ops-data@psg.com; Thu, 04 Nov 2004 06:37:24 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CPbFK-000JqT-Tu
	for v6ops@ops.ietf.org; Thu, 04 Nov 2004 06:37:23 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id iA46bJd04014;
	Thu, 4 Nov 2004 08:37:19 +0200
Date: Thu, 4 Nov 2004 08:37:19 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
cc: v6ops@ops.ietf.org
Subject: Re: Next steps
In-Reply-To: <BDAF21D4.4DBB2%jordi.palet@consulintel.es>
Message-ID: <Pine.LNX.4.61.0411040825540.3699@netcore.fi>
References: <BDAF21D4.4DBB2%jordi.palet@consulintel.es>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

On Thu, 4 Nov 2004, JORDI PALET MARTINEZ wrote:
> Agree with your comments (for example your point about security is section 4
> of the charter), in general, but reading the charter I still don't think
> there is any place where is said that we should have proceed in serial-mode.
> Should we appeal that decision ? May be I'm wrong, so somebody can provide a
> prove that this has been approved by the WG ?

It is the responsibility of the chairs and ADs to ensure that works 
gets done, and gets done with sufficient expertise and wide review 
(also outside of the WG).

Doing everything in parallel would not be possible.  It is certainly 
possible to do *something* in parallel (and so we have).

> Same with the rationale being followed to decide (by the WG) that no more
> documents are accepted as WG items, and then some are now accepted and not
> some others. Again, appeal ?

See above.

> By the way, we the "Euro6IX" folks (including the 8 bigger European Telcos),
> have proposed several documents, including operational security implications
> of IPv6. This is fully within the charter, and is being ignored as a WG
> item. Again, should we appeal ?

The fact that something is listed in the WG charter does not mean that 
WG participants must be interested on a proposed work item.

For work items we take, there must be sufficient expertise and 
interest, and energy to work on such items.

> Also the same folks proposed some works regarding operational transition
> issues, like the auto-discovery of the TEP. This work was even backed-up by
> the request of the chairs. Still not even suggested to be WG item, so I ask
> now for it. If nobody objects in 2 days, as has been done with the other
> documents, clearly is accepted. Right ? Fair enough ?

I would personally object so you have at least one ;-).  I have very 
little against taking draft-palet-v6ops-tun-auto-disc as WG item, 
except timing (it'll be needed only soon, when designing the 
solutions).

> -> Now can tell me, where it says something about the serial-mode ? If not,
> please demonstrate that the decision is done by the WG and is fair. Same for
> why only a few documents are being proposed as WG items ?

To get something done in a finite time, with sufficient expertise :-).

See my different mail on more.

> 7) Anything missing regarding DNS operation ? SMTP, SIP, other protocols ?

DNS, SMTP and SIP are done or under progress in dnsop, sip WG(s), and 
individual submission by itojun.

-- 
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 owner-v6ops@ops.ietf.org  Thu Nov  4 01:41:15 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03706
	for <v6ops-archive@lists.ietf.org>; Thu, 4 Nov 2004 01:41:14 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CPbIr-000KAz-U8
	for v6ops-data@psg.com; Thu, 04 Nov 2004 06:41:01 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CPbIq-000KAl-Of
	for v6ops@ops.ietf.org; Thu, 04 Nov 2004 06:41:01 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id iA46exn04119
	for <v6ops@ops.ietf.org>; Thu, 4 Nov 2004 08:40:59 +0200
Date: Thu, 4 Nov 2004 08:40:59 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: v6ops@ops.ietf.org
Subject: A personal take on WG's priorities..
Message-ID: <Pine.LNX.4.61.0411040837210.3699@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

Hi,

Based on the discussion on what the WG should be doing, I cooked up my 
**personal** list of what I consider to be priorities, in some rough 
categories.  As you see, there's a *LOT* that falls under the WG 
charter, and there is no way we could work on even 1/3 or 1/4 of these 
at the same time.  So, there must be some priorization.

I welcome comments especially if you think I've badly misprioritized 
document/work that relates to the v6ops charter.

======

The most important work
  - finish enterprise analysis
  - finish requirement(s) for tunneling
     * to be able to decide whether existing solution(s) are sufficient
       and if not, get started on specifying new ones
  - get started on mechanisms (somewhere else?) if needed/necessary

Pretty darn important work
  - the last spin at 3GPP analysis doc, updated IMS scenario
  - better document the ISP's broadband transition scenarios
     * draft-asadullah-v6ops-bb-deployment-scenarios-01
  - finish draft-ietf-v6ops-mech-v2
     * waiting for feedback from the IESG telechat..
  - adopt and finish draft-tschofenig-v6ops-secure-tunnels-02.txt
     * IESG requirement for draft-ietf-v6ops-mech-v2
  - figure what to do about the NAT-PT deprecation/analysis
    *  draft-aoun-v6ops-natpt-deprecate
  - (techno-political) document for v4 NAT users
    * draft-vandevelde-v6ops-nap
  - IPv6-on-by-default work, fixes need to be integrated in the IETF work
    * draft-ietf-v6ops-onlinkassumption
    * draft-ietf-v6ops-v6onbydefault
    * etc.

Important work
  - draft-ietf-v6ops-renumbering-procedure
    * needs revision to address IESG comments
  - draft-palet-v6ops-tun-auto-disc
  - draft-chown-v6ops-vlan-usage
  - figuring out how to deal with Mobile IP transition issues
  - security overview of IPv6
     * draft-savola-v6ops-security-overview

Useful work
  - revising 6to4 spec to be clearer, etc.
  - draft-palet-v6ops-solution-tun-auto-disc
  - draft-chown-v6ops-renumber-thinkabout-00
  - draft-chown-v6ops-port-scanning-implications

Difficult to say whether it has gained sufficient momentum, and/or
  whether this is the right place to do this
  - draft-palet-v6ops-auto-trans
  - draft-palet-v6ops-ipv6security
  - draft-vives-v6ops-ipv6-security-ps
  - draft-kondo-quarantine-overview-01.txt

Not sure whether it should be published as RFC, or is sufficiently relevant
  - draft-chown-v6ops-campus-transition
  - draft-morelli-v6ops-ipv6-ix

-- 
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 owner-v6ops@ops.ietf.org  Thu Nov  4 03:04:39 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24318
	for <v6ops-archive@lists.ietf.org>; Thu, 4 Nov 2004 03:04:39 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CPcaa-00045G-0Y
	for v6ops-data@psg.com; Thu, 04 Nov 2004 08:03:24 +0000
Received: from [193.180.251.49] (helo=albatross.ericsson.se)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CPcaW-00044K-Lk
	for v6ops@ops.ietf.org; Thu, 04 Nov 2004 08:03:23 +0000
Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119])
	by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id iA483FvD023931
	for <v6ops@ops.ietf.org>; Thu, 4 Nov 2004 09:03:15 +0100 (MET)
Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211);
	 Thu, 4 Nov 2004 09:03:13 +0100
Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id VJSNY5NP; Thu, 4 Nov 2004 09:03:13 +0100
Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <VJQGNAXC>; Thu, 4 Nov 2004 09:03:13 +0100
Message-ID: <C26BB8276599A44B85D52F9CE41035E1050B97F9@esealnt944.al.sw.ericsson.se>
X-Sybari-Trust: f7794126 bfd556f1 3986e8d3 00000139
From: "Karen E. Nielsen (AH/LMD)" <karen.e.nielsen@ericsson.com>
To: "'Pekka Savola'" <pekkas@netcore.fi>
Cc: "'the otter'" <2the.otter@gmail.com>, v6ops@ops.ietf.org
Subject: RE: draft-nielsen-v6ops-3GPP-zeroconf-goals-00.txt
Date: Thu, 4 Nov 2004 09:03:12 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
X-OriginalArrivalTime: 04 Nov 2004 08:03:13.0790 (UTC) FILETIME=[BBD241E0:01C4C244]
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

Pekka,

No disagreement there.

The tricky exercise, of course, is to identify 
the necessary features (the reasonable means)
that such 3GPP pilot IPv6 applications 
would depend on.

BR, Karen

> -----Original Message-----
> From: Pekka Savola [mailto:pekkas@netcore.fi]
> Sent: Tuesday, November 02, 2004 6:15 PM
> To: Karen E. Nielsen (AH/LMD)
> Cc: 'the otter'; karen.e.neilsen@ericsson.com; v6ops@ops.ietf.org
> Subject: RE: draft-nielsen-v6ops-3GPP-zeroconf-goals-00.txt
> 
> 
> On Tue, 2 Nov 2004, Karen E. Nielsen (AH/LMD) wrote:
> >> IMHO the issue I see with leaving these out is the transition
> >> mechanism
> >> becomes a solution for only the most basic of "web" type services.
> >> While this makes the solution simple, it removes the motivation for
> >> IPv6 within the 3GPP network. It is important to at least match or
> >> mimic the functionality available in the IPv4 domain.
> >
> > Tunnelling in 3GPP is not intended to provide full emulation of
> > the native IPv4 or native IPv6 services, since that would 
> basically require
> > full dual IP support in all related 3GPP signalling interfaces.
> 
> Without knowing the details here, I'll have to personally join in the 
> first mentioned sentiment: as far as I see it, the UE 
> tunneling offers 
> the operators and UE vendors the chance to pilot IPv6 application 
> deployments etc. without requiring immediate upgrades in the 3GPP 
> network.
> 
> Unless the tunneling can provide a reasonable means to test out at 
> least some potential applications that could be realized with IPv6, 
> then its applicability might be a bit questionable.
> 
> Remember, IPv6 isn't all that inrestesting just because of a dancing 
> turtle on a web page ;-).  It needs to provide a way to deploy nice 
> new applications.  Even though full functions of IPv6 were not yet 
> realized with the tentative tunneling solution, IMHO it 
> should provide 
> at least basic means to deploy some novel IPv6 applications (e.g., 
> relativng to peer-to-peer).
> 
> -- 
> 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 owner-v6ops@ops.ietf.org  Thu Nov  4 03:10:22 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24886
	for <v6ops-archive@lists.ietf.org>; Thu, 4 Nov 2004 03:10:21 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CPcgz-00057E-Q3
	for v6ops-data@psg.com; Thu, 04 Nov 2004 08:10:01 +0000
Received: from [195.212.29.137] (helo=mtagate4.uk.ibm.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CPcgv-00055T-AA
	for v6ops@ops.ietf.org; Thu, 04 Nov 2004 08:09:57 +0000
Received: from d06nrmr1307.portsmouth.uk.ibm.com (d06nrmr1307.portsmouth.uk.ibm.com [9.149.38.129])
	by mtagate4.uk.ibm.com (8.12.10/8.12.10) with ESMTP id iA489kIA229650;
	Thu, 4 Nov 2004 08:09:46 GMT
Received: from sihl.zurich.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216])
	by d06nrmr1307.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iA489jIF089488;
	Thu, 4 Nov 2004 08:09:46 GMT
Received: from zurich.ibm.com (sig-9-145-250-203.de.ibm.com [9.145.250.203])
	by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id JAA62742;
	Thu, 4 Nov 2004 09:09:44 +0100
Message-ID: <4189E3C8.1010009@zurich.ibm.com>
Date: Thu, 04 Nov 2004 09:09:44 +0100
From: Brian E Carpenter <brc@zurich.ibm.com>
Organization: IBM
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en, fr, de
MIME-Version: 1.0
To: Pekka Savola <pekkas@netcore.fi>
CC: v6ops@ops.ietf.org
Subject: Re: A personal take on WG's priorities..
References: <Pine.LNX.4.61.0411040837210.3699@netcore.fi>
In-Reply-To: <Pine.LNX.4.61.0411040837210.3699@netcore.fi>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Pekka,

Loosely speaking, this list seems OK to me personally.

Quite obviously, it would be outrageous to attempt all this
in one WG. IMHO, we need to either out-source work to other
WGs or create several new WGs with focussed charters.
Especially, we need to separate "getting known stuff
fully operational" from "doing new stuff."

    Brian

Pekka Savola wrote:
> Hi,
> 
> Based on the discussion on what the WG should be doing, I cooked up my 
> **personal** list of what I consider to be priorities, in some rough 
> categories.  As you see, there's a *LOT* that falls under the WG 
> charter, and there is no way we could work on even 1/3 or 1/4 of these 
> at the same time.  So, there must be some priorization.
> 
> I welcome comments especially if you think I've badly misprioritized 
> document/work that relates to the v6ops charter.
> 
> ======
> 
> The most important work
>  - finish enterprise analysis
>  - finish requirement(s) for tunneling
>     * to be able to decide whether existing solution(s) are sufficient
>       and if not, get started on specifying new ones
>  - get started on mechanisms (somewhere else?) if needed/necessary
> 
> Pretty darn important work
>  - the last spin at 3GPP analysis doc, updated IMS scenario
>  - better document the ISP's broadband transition scenarios
>     * draft-asadullah-v6ops-bb-deployment-scenarios-01
>  - finish draft-ietf-v6ops-mech-v2
>     * waiting for feedback from the IESG telechat..
>  - adopt and finish draft-tschofenig-v6ops-secure-tunnels-02.txt
>     * IESG requirement for draft-ietf-v6ops-mech-v2
>  - figure what to do about the NAT-PT deprecation/analysis
>    *  draft-aoun-v6ops-natpt-deprecate
>  - (techno-political) document for v4 NAT users
>    * draft-vandevelde-v6ops-nap
>  - IPv6-on-by-default work, fixes need to be integrated in the IETF work
>    * draft-ietf-v6ops-onlinkassumption
>    * draft-ietf-v6ops-v6onbydefault
>    * etc.
> 
> Important work
>  - draft-ietf-v6ops-renumbering-procedure
>    * needs revision to address IESG comments
>  - draft-palet-v6ops-tun-auto-disc
>  - draft-chown-v6ops-vlan-usage
>  - figuring out how to deal with Mobile IP transition issues
>  - security overview of IPv6
>     * draft-savola-v6ops-security-overview
> 
> Useful work
>  - revising 6to4 spec to be clearer, etc.
>  - draft-palet-v6ops-solution-tun-auto-disc
>  - draft-chown-v6ops-renumber-thinkabout-00
>  - draft-chown-v6ops-port-scanning-implications
> 
> Difficult to say whether it has gained sufficient momentum, and/or
>  whether this is the right place to do this
>  - draft-palet-v6ops-auto-trans
>  - draft-palet-v6ops-ipv6security
>  - draft-vives-v6ops-ipv6-security-ps
>  - draft-kondo-quarantine-overview-01.txt
> 
> Not sure whether it should be published as RFC, or is sufficiently relevant
>  - draft-chown-v6ops-campus-transition
>  - draft-morelli-v6ops-ipv6-ix
> 



From owner-v6ops@ops.ietf.org  Thu Nov  4 03:26:39 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26226
	for <v6ops-archive@lists.ietf.org>; Thu, 4 Nov 2004 03:26:39 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CPcwo-0007II-Jx
	for v6ops-data@psg.com; Thu, 04 Nov 2004 08:26:22 +0000
Received: from [213.172.48.142] (helo=consulintel.es)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CPcwn-0007I3-Gl
	for v6ops@ops.ietf.org; Thu, 04 Nov 2004 08:26:21 +0000
Received: from [192.168.0.101] ([150.254.185.155])
	by consulintel.es (consulintel.es [127.0.0.1])
	(MDaemon.PRO.v7.2.0.R)
	with ESMTP id md50000555810.msg
	for <v6ops@ops.ietf.org>; Thu, 04 Nov 2004 09:31:46 +0100
User-Agent: Microsoft-Entourage/10.1.4.030702.0
Date: Thu, 04 Nov 2004 09:23:17 +0100
Subject: Re: Next steps
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: <v6ops@ops.ietf.org>
Message-ID: <BDAFA585.4DCFC%jordi.palet@consulintel.es>
In-Reply-To: <20041104012404.GA4532@nokia.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Spam-Processed: consulintel.es, Thu, 04 Nov 2004 09:31:46 +0100
	(not processed: message from valid local sender)
X-MDRemoteIP: 150.254.185.155
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ops.ietf.org
Reply-To: jordi.palet@consulintel.es
X-MDAV-Processed: consulintel.es, Thu, 04 Nov 2004 09:31:50 +0100
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi David,

As in IETF everything is done via I-Ds, it will be much better to have
"something", to detail a little bit some options about how to proceed.
Propose several directions, may be, etc. Basically speaking-up now instead
of just waiting for the mic, so the people can start thinking and providing
inputs, which we all know is already difficult.

You don't think so ?

Regards,
Jordi


> De: David Kessens <david.kessens@nokia.com>
> Responder a: owner-v6ops@ops.ietf.org
> Fecha: Wed, 3 Nov 2004 17:24:04 -0800
> Para: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
> CC: v6ops@ops.ietf.org
> Asunto: Re: Next steps
> 
> 
> Jordi,
> 
> On Thu, Nov 04, 2004 at 12:01:14AM +0100, JORDI PALET MARTINEZ wrote:
>> Well, what I expected is a document or at least an email explaining this:
>> 
>> Discussion of the way forward - 15 mins, Chairs/ADs
>>   - GOAL: discuss and get consensus on how to proceed from here
>> 
>> The AD indicated that he asked for this, so I guess we should have "some"
>> document that at a minimum introduce the topic, options, etc. !
> 
> I think I already explained this to you:
> 
> We would like to discuss how to proceed from where we are, now that
> most of our major milestones are accomplished.
> 
> It is up to the community/working group to form a consensus view
> onwhere we want to go from here.
> 
> Margaret & Jonne already gave their views. Not speaking as an AD, I
> like an approach as proposed by Margaret and supported by Jonne.
> 
> Speaking as an AD, the part of the title of the agenda topic that says
> 'get consensus' was perhaps not the best choice of words. I would like
> to use the time to bootstrap the discussion on what is next and get
> some sense of the room for which directions make sense.
> 
> David Kessens
> ---
> 
> 



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






From owner-v6ops@ops.ietf.org  Thu Nov  4 03:44:17 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27432
	for <v6ops-archive@lists.ietf.org>; Thu, 4 Nov 2004 03:44:17 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CPdDW-0008zX-Lc
	for v6ops-data@psg.com; Thu, 04 Nov 2004 08:43:38 +0000
Received: from [66.54.152.27] (helo=jive.SoftHome.net)
	by psg.com with smtp (Exim 4.41 (FreeBSD))
	id 1CPdDV-0008zD-Kp
	for v6ops@ops.ietf.org; Thu, 04 Nov 2004 08:43:37 +0000
Received: (qmail 30397 invoked by uid 417); 4 Nov 2004 08:31:32 -0000
Received: from charleston-.softhome.net (HELO softhome.net) (172.16.2.12)
  by shunt-smtp-out-0 with SMTP; 4 Nov 2004 08:31:32 -0000
Received: from XPNERICK ([193.17.42.1])
  (AUTH: LOGIN ericlklein@softhome.net)
  by softhome.net with esmtp; Thu, 04 Nov 2004 01:31:30 -0700
Message-ID: <007601c4c248$8a92d910$4e081eac@ttitelecom.com>
From: "EricLKlein" <ericlklein@softhome.net>
To: v6ops@ops.ietf.org
References: <Pine.LNX.4.61.0411040837210.3699@netcore.fi> <4189E3C8.1010009@zurich.ibm.com>
Subject: Re: A personal take on WG's priorities..
Date: Thu, 4 Nov 2004 10:30:27 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

From: "Brian
> Quite obviously, it would be outrageous to attempt all this
> in one WG. IMHO, we need to either out-source work to other
> WGs or create several new WGs with focussed charters.
> Especially, we need to separate "getting known stuff
> fully operational" from "doing new stuff."

Is it possible to try to set up "sub-WG" areas and recruit more specialized
people into these areas?

I am thinking (of the top of my head) of three subgroups:
- Enterprise - would include migration issues, etc.
- ISPs - would handle tunnels, interconnections, etc
- IPv6 Security - would handle NAT-PT, depreciating NAT in IPv6, etc.

Just a thought.
Eric





From owner-v6ops@ops.ietf.org  Thu Nov  4 07:32:30 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14406
	for <v6ops-archive@lists.ietf.org>; Thu, 4 Nov 2004 07:32:30 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CPgjK-000AHj-3A
	for v6ops-data@psg.com; Thu, 04 Nov 2004 12:28:42 +0000
Received: from [193.180.251.47] (helo=penguin.ericsson.se)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CPgjC-000AH2-HV
	for v6ops@ops.ietf.org; Thu, 04 Nov 2004 12:28:34 +0000
Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118])
	by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id iA4CSXh5028652
	for <v6ops@ops.ietf.org>; Thu, 4 Nov 2004 13:28:33 +0100 (MET)
Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211);
	 Thu, 4 Nov 2004 13:28:33 +0100
Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id VJSN6W4D; Thu, 4 Nov 2004 13:28:33 +0100
Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <VJQGNCMG>; Thu, 4 Nov 2004 13:28:33 +0100
Message-ID: <C26BB8276599A44B85D52F9CE41035E1050B9800@esealnt944.al.sw.ericsson.se>
X-Sybari-Trust: fea78f76 bfd556f1 3986e8d3 00000139
From: "Karen E. Nielsen (AH/LMD)" <karen.e.nielsen@ericsson.com>
To: "'the otter'" <2the.otter@gmail.com>,
        "Soininen Jonne (Nokia-NET/Helsinki)" <jonne.soininen@nokia.com>
Cc: v6ops@ops.ietf.org
Subject: RE: draft-nielsen-v6ops-3GPP-zeroconf-goals-00.txt
Date: Thu, 4 Nov 2004 13:28:32 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
X-OriginalArrivalTime: 04 Nov 2004 12:28:33.0183 (UTC) FILETIME=[CC84DAF0:01C4C269]
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

Stranger ...!(

> 
> Hi,
> The reasons an operator may make use of IP address to account mapping
> at a service is to:
> - provide automatic sign-on to a service (-it would be annoying to
> have to insert username/password on a handset everytime you 
> use WAP or MMS)
> - determine from the IP address something about the users settings (-
> for example, have they requested Location Based Services to be turned
> off)
> - event based PUSH (-for example, a messaging server looks up user
> account, obtains IP address and pushes email to terminal)
> 
> If we cannot assume any significance about the IPv6 address then these
> functions must be achieved at a different layer. At the moment in
> IPv4, there exists a consistent way of determining User ID from IP
> address.
> 

With private IPv6 addresses being generated by the UE in the IPv6 domain there will be
no direct way to correlate IPv6 addresses with a User ID - that's why for example
an IMS registration must be performed anew when the UE generates a new address.

> Sure, these solutions only exist in the operator networks (and
> directly connected 3rd Party) but this is still important. The IP
> address has a lot of significance within the internal network of the
> operator. And I mean just the Gi network, forget all the others. With
> regard transition methods, these play a significant part in the large
> international operator's network, when you consider these are actually
> a number of disjoint national operators' access-networks trying to
> access common services.
> 
> It would be neat to continue the identity in the v6 domain. The
> solution would just need to be deterministic. I purposely didn't want
> to look at the solutions, and stick to goals, but we may think about:
> 1) a second IPv6 RADIUS/DHCP server for DHCP to tunnels which is
> interrogated in the IPv6 domain (is this against the zero 
> config goals?); or
> 2) use a PREFIX function (c.f. NAT-PT 96bit PREFIX) where IPv4 address
> at source (and in the RADIUS DB) can be determined from the incoming
> IPv6 address (perhaps security/fraud issues?)
> 
> Again, if this is not going to feature in this draft, can we 
> state this.
> 

Yes.

What you suggest above to me sounds very much like tunnel server
registration - at least if you are speaking about service registration only,
I may not understand how DHCP comes into play


> Note on standards - I cannot see the 3GPP standardising the Gi in
> anyway. However barring IMS this is where all the IP Services reside.
> So IMHO I think the standards will not have all the answers, and
> looking at what happens in practice is beneficial. But Is the
> motivation for this draft IMS alone? I interpret "3GPP" to
> mean this draft is applicable to mobile operator services generally,
> not IMS alone.
> 

Personally, my motivation has been driven by the termed (at least) Ipv6 only IMS services
(or Ipv6-only IMS operator networks) and the explicit need for a transition solution for these, 
but that's not to say that this should be the only need taken care of by zeroconf tunnelling.

BR, Karen

> Thanks & Regards,
> 
> 
> 
> On Tue, 02 Nov 2004 14:18:03 +0200, Soininen Jonne
> (Nokia-NET/Helsinki) <jonne.soininen@nokia.com> wrote:
> > Hello,
> >
> > (Chair hat on)
> > It would be nice if you could identify yourself. It is not nice to
> > discuss on this kind of list with anonymous people.
> > (Chair hat off)
> >
> > Below I have put some comments:
> >
> >
> > On Tue, 2004-11-02 at 00:45, ext the otter wrote:
> >> Hi Karen,
> >> Regarding the draft 
> draft-nielsen-v6ops-3GPP-zeroconf-goals-00.txt, I
> >> would like to ask about push functionality and user identity within
> >> the 3GPP network.
> >> PUSH relates to tunnel duration/accessibility:
> >>
> >>>6.7. Tunnel Link Sustainability
> >>>
> >>>  The tunnel link established in between a host deploying Zero-
> >>>  Configuration Tunneling and an associated Tunnel Server should be
> >>>  expected to remain in administrative active state for 
> the lifetime of
> >>>  the IPv6 address provided to the host.
> >>>
> >>>  The tunnel protocol must not mandate keep-alive messages to be
> >>>  transmitted by the host simply in order to sustain tunnel link
> >>>  connectivity.
> >>
> >> Is it intended that the tunnel remain up while the UE has an active
> >> PDP context?
> >> In an "always-on" network there may be services that perform PUSH
> >> (i.e. server initiated) functions - is it a requirement to 
> allow IP PUSH from
> >> the IPv6 domain toward the client?
> >> I would suggest that this be a requirement or it will limit the
> >> service use cases for this solution.
> >> The PUSH functionality leads on to the User Identity issue which
> >> relates mainly to this section:
> >>
> >
> > I think the requirement is that the IPv6 address supports 
> "always-on".
> > Thus, keeping the IPv6 address relatively stable - at least the IPv6
> > address has to be as table as the IPv4 address.
> > In addition, I don't think there are any restrictions on 
> what kind of
> > protocols/services/applications are used over the tunnel.
> >
> >
> >
> >>>6.6. Address Assignment
> >>>
> >>>  The tunnel protocol must allow for the assignment of at least one
> >>>  globally routable (/128) IPv6 unicast address to use for tunneled
> >>>  IPv6 connectivity over the link provided by the 
> Zero-Configuration
> >>>  Tunneling mechanism.
> >>
> >> 3GPP networks may utilise a database that combines 
> authentication and
> >> DHCP functions (RADIUS + database). This ensures there is an
> >> authoritative system that can provide "User Identity", 
> that is to say link
> >> IP address to User Account. A service can then query the 
> data base to
> >> resolve an IP address to a User account or vice versa. Is the IPv6
> >> address assignment for the tunnel client compatible with 
> this model?
> >> If this is not provided then some types of services in the 
> IPv6 domain
> >> will not work. May I suggest that maintaining user ID 
> mapping via IP
> >> address be a goal.
> >> If these are not to be goals then perhaps this could be stated.
> >
> > The 3GPP operator may choose to use this kind of 
> information in their
> > networks. However, usage of these mechanisms are to my understanding
> > optional in the 3GPP specifications (29.061). I don't know 
> anyways what
> > would be the use case for doing this kind of IP address to MSISDN
> > mapping.
> >
> > It may be more difficult to map the tunneled IPv6 address 
> to the MSISDN
> > of the user, but most probably doable.
> >
> > If there is a need to have _exactly_ the same functionality 
> as in native
> > IPv4, it is better to use native IPv6 over GPRS.
> >>
> >> IMHO the issue I see with leaving these out is the 
> transition mechanism
> >> becomes a solution for only the most basic of "web" type services.
> >> While this makes the solution simple, it removes the motivation for
> >> IPv6 within the 3GPP network. It is important to at least match or
> >> mimic the functionality available in the IPv4 domain.
> >
> > The tunneling mechanism has to support stable addressing - 
> that's right.
> > That is absolutely necessary. However, I don't understand this IP
> > address to MSISDN mapping requirement as that information is not
> > available outside the operators network anyways.
> >
> > Cheers,
> >
> > Jonne.
> >
> >>
> >> Best Regards,
> >> N
> > --
> > Jonne Soininen
> > Nokia
> >
> > Tel: +358 40 527 46 34
> > E-mail: jonne.soininen@nokia.com
> >
> 



From owner-v6ops@ops.ietf.org  Thu Nov  4 07:55:55 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15936
	for <v6ops-archive@lists.ietf.org>; Thu, 4 Nov 2004 07:55:55 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CPh8l-000DNY-Qj
	for v6ops-data@psg.com; Thu, 04 Nov 2004 12:54:59 +0000
Received: from [213.172.48.142] (helo=consulintel.es)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CPh8b-000DMU-EH
	for v6ops@ops.ietf.org; Thu, 04 Nov 2004 12:54:49 +0000
Received: from [141.39.27.12] ([141.39.27.12])
	by consulintel.es (consulintel.es [127.0.0.1])
	(MDaemon.PRO.v7.2.0.R)
	with ESMTP id md50000557277.msg
	for <v6ops@ops.ietf.org>; Thu, 04 Nov 2004 14:00:15 +0100
User-Agent: Microsoft-Entourage/10.1.4.030702.0
Date: Thu, 04 Nov 2004 10:55:59 +0100
Subject: FW: Next steps
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: <v6ops@ops.ietf.org>
Message-ID: <BDAFBB3F.4DD4B%jordi.palet@consulintel.es>
In-Reply-To: <BDAFA47B.4DCFA%jordi.palet@consulintel.es>
Mime-version: 1.0
X-Priority: 1
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Spam-Processed: consulintel.es, Thu, 04 Nov 2004 14:00:15 +0100
	(not processed: message from valid local sender)
X-MDRemoteIP: 141.39.27.12
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ops.ietf.org
Reply-To: jordi.palet@consulintel.es
X-MDAV-Processed: consulintel.es, Thu, 04 Nov 2004 14:00:17 +0100
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-2.4 required=5.0 tests=BAYES_00,PRIORITY_NO_NAME,
	X_PRIORITY_HIGH autolearn=no version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Margaret,

Your point regarding the non-serial mode is quite interesting ;-)

Part of the work that I mention has already started a year ago, but is being
ignored by the chairs (as WG items), unfairly with other work, even when
some documents had been requested by them !

Regards,
Jordi
 

> De: Margaret Wasserman <margaret@thingmagic.com>
> Responder a: owner-v6ops@ops.ietf.org
> Fecha: Wed, 3 Nov 2004 22:51:00 -0500
> Para: jordi.palet@consulintel.es, <v6ops@ops.ietf.org>
> Asunto: Re: Next steps
> 
> 
> Hi Jordi,
> 
> At 12:01 AM +0100 11/4/04, JORDI PALET MARTINEZ wrote:
>> Agree with your comments (for example your point about security is section 4
>> of the charter), in general, but reading the charter I still don't think
>> there is any place where is said that we should have proceed in serial-mode.
> 
> I wrote the original charter for this WG, and he intention at the
> time was not to proceed in serial mode.
> 
> We were supposed to work on the scenarios/analysis before continuing
> work on the coexistence/transition mechanisms, but the operational
> work was intended to happen in parallel.  At least during the time
> that I was chairing the group, we did get some ISP/operator feedback
> and do some work on operational work.  We also continued working on
> the documents that summarized v6 work needed in various areas,
> provided advice to several areas that did lead to some important work
> and published them.
> 
> However, it was always a challenge (before and after the ngtrans ->
> v6ops transition) to get this particular WG actively engaged in the
> work of the group.
> 
> I think that many of the efforts you have mentioned would be good
> efforts for this group to undertake.
> 
> Margaret
> 
> 
> 
> 



------ Fin del mensaje reenviado



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






From owner-v6ops@ops.ietf.org  Thu Nov  4 07:55:58 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15957
	for <v6ops-archive@lists.ietf.org>; Thu, 4 Nov 2004 07:55:58 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CPh8z-000DRT-QV
	for v6ops-data@psg.com; Thu, 04 Nov 2004 12:55:13 +0000
Received: from [213.172.48.142] (helo=consulintel.es)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CPh8e-000DMq-5k
	for v6ops@ops.ietf.org; Thu, 04 Nov 2004 12:54:52 +0000
Received: from [141.39.27.12] ([141.39.27.12])
	by consulintel.es (consulintel.es [127.0.0.1])
	(MDaemon.PRO.v7.2.0.R)
	with ESMTP id md50000557276.msg
	for <v6ops@ops.ietf.org>; Thu, 04 Nov 2004 14:00:15 +0100
User-Agent: Microsoft-Entourage/10.1.4.030702.0
Date: Thu, 04 Nov 2004 10:55:21 +0100
Subject: Re: A personal take on WG's priorities..
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: <v6ops@ops.ietf.org>
Message-ID: <BDAFBB19.4DD4A%jordi.palet@consulintel.es>
In-Reply-To: <4189E3C8.1010009@zurich.ibm.com>
Mime-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
X-Spam-Processed: consulintel.es, Thu, 04 Nov 2004 14:00:15 +0100
	(not processed: message from valid local sender)
X-MDRemoteIP: 141.39.27.12
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ops.ietf.org
Reply-To: jordi.palet@consulintel.es
X-MDAV-Processed: consulintel.es, Thu, 04 Nov 2004 14:00:17 +0100
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-3.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

Hi Brian,

May be I'm wrong, but if the objective to outsource some of the work is to
"evacuate" it faster, I think is not the right way.

I mean, if they are within the charter, they are operational issues, pushing
it outside, will mean some of the people that is doing effort here, will
divide his time following up to WGs (at least), attending 2 meetings, etc.
At the end, some times this can be rather more time consuming that
proceeding here. I've this experience in projects, when you divide the work
in several WGs and then becomes fragmented, and the people, who is limited
in number and resources, availability, etc., tend to keep only with part of
the work, very concentrated and missing the overall picture.

Consequently, I will agree with this only in case we have extra effort,
which is not the case, but in general in IETF on the contrary. Less people
less effort with the time ..., unfortunately.

I will agree that if we have something that is clearly specific to an
existing WG, then it should be forwarded there. Similarly, if there is some
work that requires a very focused effort, then we should try to create a new
WG, probably.

Regards,
Jordi


> De: Brian E Carpenter <brc@zurich.ibm.com>
> Organizaci=F3n: IBM
> Responder a: owner-v6ops@ops.ietf.org
> Fecha: Thu, 04 Nov 2004 09:09:44 +0100
> Para: Pekka Savola <pekkas@netcore.fi>
> CC: v6ops@ops.ietf.org
> Asunto: Re: A personal take on WG's priorities..
>=20
> Pekka,
>=20
> Loosely speaking, this list seems OK to me personally.
>=20
> Quite obviously, it would be outrageous to attempt all this
> in one WG. IMHO, we need to either out-source work to other
> WGs or create several new WGs with focussed charters.
> Especially, we need to separate "getting known stuff
> fully operational" from "doing new stuff."
>=20
>   Brian
>=20
> Pekka Savola wrote:
>> Hi,
>>=20
>> Based on the discussion on what the WG should be doing, I cooked up my
>> **personal** list of what I consider to be priorities, in some rough
>> categories.  As you see, there's a *LOT* that falls under the WG
>> charter, and there is no way we could work on even 1/3 or 1/4 of these
>> at the same time.  So, there must be some priorization.
>>=20
>> I welcome comments especially if you think I've badly misprioritized
>> document/work that relates to the v6ops charter.
>>=20
>> =3D=3D=3D=3D=3D=3D
>>=20
>> The most important work
>>  - finish enterprise analysis
>>  - finish requirement(s) for tunneling
>>     * to be able to decide whether existing solution(s) are sufficient
>>       and if not, get started on specifying new ones
>>  - get started on mechanisms (somewhere else?) if needed/necessary
>>=20
>> Pretty darn important work
>>  - the last spin at 3GPP analysis doc, updated IMS scenario
>>  - better document the ISP's broadband transition scenarios
>>     * draft-asadullah-v6ops-bb-deployment-scenarios-01
>>  - finish draft-ietf-v6ops-mech-v2
>>     * waiting for feedback from the IESG telechat..
>>  - adopt and finish draft-tschofenig-v6ops-secure-tunnels-02.txt
>>     * IESG requirement for draft-ietf-v6ops-mech-v2
>>  - figure what to do about the NAT-PT deprecation/analysis
>>    *  draft-aoun-v6ops-natpt-deprecate
>>  - (techno-political) document for v4 NAT users
>>    * draft-vandevelde-v6ops-nap
>>  - IPv6-on-by-default work, fixes need to be integrated in the IETF work
>>    * draft-ietf-v6ops-onlinkassumption
>>    * draft-ietf-v6ops-v6onbydefault
>>    * etc.
>>=20
>> Important work
>>  - draft-ietf-v6ops-renumbering-procedure
>>    * needs revision to address IESG comments
>>  - draft-palet-v6ops-tun-auto-disc
>>  - draft-chown-v6ops-vlan-usage
>>  - figuring out how to deal with Mobile IP transition issues
>>  - security overview of IPv6
>>     * draft-savola-v6ops-security-overview
>>=20
>> Useful work
>>  - revising 6to4 spec to be clearer, etc.
>>  - draft-palet-v6ops-solution-tun-auto-disc
>>  - draft-chown-v6ops-renumber-thinkabout-00
>>  - draft-chown-v6ops-port-scanning-implications
>>=20
>> Difficult to say whether it has gained sufficient momentum, and/or
>>  whether this is the right place to do this
>>  - draft-palet-v6ops-auto-trans
>>  - draft-palet-v6ops-ipv6security
>>  - draft-vives-v6ops-ipv6-security-ps
>>  - draft-kondo-quarantine-overview-01.txt
>>=20
>> Not sure whether it should be published as RFC, or is sufficiently relevant
>>  - draft-chown-v6ops-campus-transition
>>  - draft-morelli-v6ops-ipv6-ix
>>=20
>=20
>=20



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






From owner-v6ops@ops.ietf.org  Thu Nov  4 07:56:16 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15981
	for <v6ops-archive@lists.ietf.org>; Thu, 4 Nov 2004 07:56:16 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CPh9B-000DTG-Qf
	for v6ops-data@psg.com; Thu, 04 Nov 2004 12:55:25 +0000
Received: from [213.172.48.142] (helo=consulintel.es)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CPh8k-000DNG-K3
	for v6ops@ops.ietf.org; Thu, 04 Nov 2004 12:54:59 +0000
Received: from [141.39.27.12] ([141.39.27.12])
	by consulintel.es (consulintel.es [127.0.0.1])
	(MDaemon.PRO.v7.2.0.R)
	with ESMTP id md50000557278.msg
	for <v6ops@ops.ietf.org>; Thu, 04 Nov 2004 14:00:15 +0100
User-Agent: Microsoft-Entourage/10.1.4.030702.0
Date: Thu, 04 Nov 2004 11:22:01 +0100
Subject: Re: A personal take on WG's priorities..
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: <v6ops@ops.ietf.org>
Message-ID: <BDAFC159.4DD4D%jordi.palet@consulintel.es>
In-Reply-To: <Pine.LNX.4.61.0411040837210.3699@netcore.fi>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Spam-Processed: consulintel.es, Thu, 04 Nov 2004 14:00:15 +0100
	(not processed: message from valid local sender)
X-MDRemoteIP: 141.39.27.12
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ops.ietf.org
Reply-To: jordi.palet@consulintel.es
X-MDAV-Processed: consulintel.es, Thu, 04 Nov 2004 14:00:17 +0100
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Pekka,

In general good proposal. I will like to suggest some changes, see below,
already prioritized following the criteria that I think is required, and
simplified a little bit.

Regards,
Jordi

Group 1
> The most important work
> - finish enterprise analysis
> - finish requirement(s) for tunneling
>    * to be able to decide whether existing solution(s) are sufficient
>      and if not, get started on specifying new ones
> - get started on mechanisms (somewhere else?) if needed/necessary

I will say that is not good that a new WG should take care of new mechanisms
(if they are required). This will slow down the process too much (minimum 6
months), and it not clear that we can't do that with the current charter, or
even a small modification of it.

Also, I think this
> - draft-palet-v6ops-tun-auto-disc
belongs to what I called Group 1, and is ready to be closed. Otherwise will
be good the received inputs, objections or whatever !

Group 2
> Pretty darn important work
> - the last spin at 3GPP analysis doc, updated IMS scenario
> - better document the ISP's broadband transition scenarios
>    * draft-asadullah-v6ops-bb-deployment-scenarios-01
> - finish draft-ietf-v6ops-mech-v2
>    * waiting for feedback from the IESG telechat..
> - adopt and finish draft-tschofenig-v6ops-secure-tunnels-02.txt
>    * IESG requirement for draft-ietf-v6ops-mech-v2
> - figure what to do about the NAT-PT deprecation/analysis
>   *  draft-aoun-v6ops-natpt-deprecate
> - (techno-political) document for v4 NAT users
>   * draft-vandevelde-v6ops-nap
> - IPv6-on-by-default work, fixes need to be integrated in the IETF work
>   * draft-ietf-v6ops-onlinkassumption
>   * draft-ietf-v6ops-v6onbydefault
>   * etc.
I think
> - draft-palet-v6ops-solution-tun-auto-disc
belongs to this group, and is 80% ready. Is very useful for the zeroconfig,
assisted tunneling, etc.

Group 3
> Important work
> - draft-ietf-v6ops-renumbering-procedure
>   * needs revision to address IESG comments
> - draft-chown-v6ops-vlan-usage
> - figuring out how to deal with Mobile IP transition issues
> - security overview of IPv6
>    * draft-savola-v6ops-security-overview

Group 4
> Useful work
> - revising 6to4 spec to be clearer, etc.
> - draft-chown-v6ops-renumber-thinkabout-00
> - draft-chown-v6ops-port-scanning-implications

Group 5
> Difficult to say whether it has gained sufficient momentum, and/or
> whether this is the right place to do this
> - draft-palet-v6ops-auto-trans
> - draft-palet-v6ops-ipv6security
> - draft-vives-v6ops-ipv6-security-ps
> - draft-kondo-quarantine-overview-01.txt

I'm tempted to move all this to the Group 2 or 3, together with the
security-overview. If this work needs to specify new protocols, then I might
consider another WG (existing probably, not necessarily a new one), but I
believe it can be approached with existing protocols within IETF.
I consider security an extremely important issue for the deployment of IPv6,
as an operational issue that falls clearly in the scope of our charter.

By the way, I don't think is a question of momentum, is a question of people
reviewing, and we all know that the problem is the same with other very
important documents, which at the end pass by "no objection" despite Jim
observations ! Let's be honest with ourselves, please ! I think is very
stupid to try to convince ourselves about what is so evident. And yes is my
own fault also, I will like to do more work review more documents, but
specially the last 3-4 months has been almost impossible. Now I've plenty of
time during Xmas and will do much more.

Group 6
> Not sure whether it should be published as RFC, or is sufficiently relevant
> - draft-chown-v6ops-campus-transition
> - draft-morelli-v6ops-ipv6-ix

Not sure either, but I will say is part of the scenarios documents.

My conclusion is that we will have probably only 3 groups instead of 6,
which can proceed almost in parallel, even if takes a few extra months
(3-6), because that will be the same delay it will take creating a new WG,
or even outsourcing to existing ones.

Missing items, other future candidate work which fall in the actual charter
? Work that is very close related and requires a charter modification to be
approached here, if its the best place to be done ?

Views from the rest of the WG, please ?

Regards,
Jordi

> De: Pekka Savola <pekkas@netcore.fi>
> Responder a: owner-v6ops@ops.ietf.org
> Fecha: Thu, 4 Nov 2004 08:40:59 +0200 (EET)
> Para: v6ops@ops.ietf.org
> Asunto: A personal take on WG's priorities..
> 
> Hi,
> 
> Based on the discussion on what the WG should be doing, I cooked up my
> **personal** list of what I consider to be priorities, in some rough
> categories.  As you see, there's a *LOT* that falls under the WG
> charter, and there is no way we could work on even 1/3 or 1/4 of these
> at the same time.  So, there must be some priorization.
> 
> I welcome comments especially if you think I've badly misprioritized
> document/work that relates to the v6ops charter.
> 
> ======
> 
> The most important work
> - finish enterprise analysis
> - finish requirement(s) for tunneling
>    * to be able to decide whether existing solution(s) are sufficient
>      and if not, get started on specifying new ones
> - get started on mechanisms (somewhere else?) if needed/necessary
> 
> Pretty darn important work
> - the last spin at 3GPP analysis doc, updated IMS scenario
> - better document the ISP's broadband transition scenarios
>    * draft-asadullah-v6ops-bb-deployment-scenarios-01
> - finish draft-ietf-v6ops-mech-v2
>    * waiting for feedback from the IESG telechat..
> - adopt and finish draft-tschofenig-v6ops-secure-tunnels-02.txt
>    * IESG requirement for draft-ietf-v6ops-mech-v2
> - figure what to do about the NAT-PT deprecation/analysis
>   *  draft-aoun-v6ops-natpt-deprecate
> - (techno-political) document for v4 NAT users
>   * draft-vandevelde-v6ops-nap
> - IPv6-on-by-default work, fixes need to be integrated in the IETF work
>   * draft-ietf-v6ops-onlinkassumption
>   * draft-ietf-v6ops-v6onbydefault
>   * etc.
> 
> Important work
> - draft-ietf-v6ops-renumbering-procedure
>   * needs revision to address IESG comments
> - draft-palet-v6ops-tun-auto-disc
> - draft-chown-v6ops-vlan-usage
> - figuring out how to deal with Mobile IP transition issues
> - security overview of IPv6
>    * draft-savola-v6ops-security-overview
> 
> Useful work
> - revising 6to4 spec to be clearer, etc.
> - draft-palet-v6ops-solution-tun-auto-disc
> - draft-chown-v6ops-renumber-thinkabout-00
> - draft-chown-v6ops-port-scanning-implications
> 
> Difficult to say whether it has gained sufficient momentum, and/or
> whether this is the right place to do this
> - draft-palet-v6ops-auto-trans
> - draft-palet-v6ops-ipv6security
> - draft-vives-v6ops-ipv6-security-ps
> - draft-kondo-quarantine-overview-01.txt
> 
> Not sure whether it should be published as RFC, or is sufficiently relevant
> - draft-chown-v6ops-campus-transition
> - draft-morelli-v6ops-ipv6-ix
> 
> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> 
> 



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






From owner-v6ops@ops.ietf.org  Thu Nov  4 08:06:24 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16574
	for <v6ops-archive@lists.ietf.org>; Thu, 4 Nov 2004 08:06:24 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CPhIp-000Epb-HH
	for v6ops-data@psg.com; Thu, 04 Nov 2004 13:05:23 +0000
Received: from [161.114.64.103] (helo=zmamail03.zma.compaq.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CPhIl-000Eo5-OA
	for v6ops@ops.ietf.org; Thu, 04 Nov 2004 13:05:19 +0000
Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186])
	by zmamail03.zma.compaq.com (Postfix) with ESMTP id 45618A5A3
	for <v6ops@ops.ietf.org>; Thu,  4 Nov 2004 08:05:19 -0500 (EST)
Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211);
	 Thu, 4 Nov 2004 08:05:18 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: Tunnel Discovery
Date: Thu, 4 Nov 2004 08:05:28 -0500
Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B07C4C4F1@tayexc13.americas.cpqcorp.net>
Thread-Topic: Tunnel Discovery
Thread-Index: AcTCbvSCCZUayn0wTpWkn3SsU74zlQ==
From: "Bound, Jim" <jim.bound@hp.com>
To: <v6ops@ops.ietf.org>
X-OriginalArrivalTime: 04 Nov 2004 13:05:19.0057 (UTC) FILETIME=[EF528410:01C4C26E]
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

Appears to me we have a few specs doing tunnel endpoint discovery or
automation of tunnels.  At this point I think we need to see if we need
one document.  Two I reviewed are below:

draft-palet-v6ops-solution-tun-auto-disc-01.txt

The above has good uses cases but I am not clear DNS should be used in
the manner suggested operationally.

draft-ietf-v6ops-assisted-tunneling-requirements-01.txt

The above is approaching the problem correctly and a good piece of work.
And also a good vechicle to documet the various issues and opportunities
for work.

Does the working group believe tunnel discovery is important to automate
or have means to set up policy or do we leave to the market, given all
other work we have to do?  I don't know right now?

/jim



From owner-v6ops@ops.ietf.org  Thu Nov  4 08:25:42 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18514
	for <v6ops-archive@lists.ietf.org>; Thu, 4 Nov 2004 08:25:42 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CPhbY-000Huu-J3
	for v6ops-data@psg.com; Thu, 04 Nov 2004 13:24:44 +0000
Received: from [192.160.51.76] (helo=smtp-bedford.mitre.org)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CPhbU-000HuH-Jy
	for v6ops@ops.ietf.org; Thu, 04 Nov 2004 13:24:40 +0000
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1])
	by smtp-bedford.mitre.org (8.11.6/8.11.6) with SMTP id iA4DOe902118
	for <v6ops@ops.ietf.org>; Thu, 4 Nov 2004 08:24:40 -0500
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1])
	by smtp-bedford.mitre.org (Postfix) with ESMTP id DDF7ABF01
	for <v6ops@ops.ietf.org>; Thu,  4 Nov 2004 08:24:39 -0500 (EST)
Received: from MAILHUB1 (mailhub1.mitre.org [129.83.20.31])
	by smtp-bedford.mitre.org (8.11.6/8.11.6) with ESMTP id iA4DOdQ02088
	for <v6ops@ops.ietf.org>; Thu, 4 Nov 2004 08:24:39 -0500
Received: from mm113749-pc.mitre.org (128.29.24.17) by mailhub1.mitre.org with SMTP
        id 10458067; Thu, 04 Nov 2004 08:24:30 -0500
From: "Sham Chakravorty" <schakra@mitre.org>
To: <v6ops@ops.ietf.org>
Subject: RE: A personal take on WG's priorities..
Date: Thu, 4 Nov 2004 08:24:29 -0500
Message-ID: <012c01c4c271$9d19c020$11181d80@MITRE.ORG>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
In-reply-to: <007601c4c248$8a92d910$4e081eac@ttitelecom.com>
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Importance: Normal
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

In this regard, would it make sense to add IPv6 Flow Label usage in a
"sub-WG" area such as Enterprise or IPv6 Traffic Modeling?  One would think
this is one of the  key IPv6 operations areas.  It seems to me we are
focused only in a few, narrowly focused areas of IPv6 operations (as
reflected in the charter).

Sham Chakravorty

-----Original Message-----
From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf
Of EricLKlein
Sent: Thursday, November 04, 2004 3:30 AM
To: v6ops@ops.ietf.org
Subject: Re: A personal take on WG's priorities..


From: "Brian
> Quite obviously, it would be outrageous to attempt all this
> in one WG. IMHO, we need to either out-source work to other
> WGs or create several new WGs with focussed charters.
> Especially, we need to separate "getting known stuff
> fully operational" from "doing new stuff."

Is it possible to try to set up "sub-WG" areas and recruit more specialized
people into these areas?

I am thinking (of the top of my head) of three subgroups:
- Enterprise - would include migration issues, etc.
- ISPs - would handle tunnels, interconnections, etc
- IPv6 Security - would handle NAT-PT, depreciating NAT in IPv6, etc.

Just a thought.
Eric








From owner-v6ops@ops.ietf.org  Thu Nov  4 08:40:37 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20012
	for <v6ops-archive@lists.ietf.org>; Thu, 4 Nov 2004 08:40:37 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CPhpk-000Jmo-He
	for v6ops-data@psg.com; Thu, 04 Nov 2004 13:39:24 +0000
Received: from [204.127.202.56] (helo=sccrmhc12.comcast.net)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CPhpa-000Jm2-F7
	for v6ops@ops.ietf.org; Thu, 04 Nov 2004 13:39:14 +0000
Received: from dfnjgl21 (c-24-1-97-29.client.comcast.net[24.1.97.29])
          by comcast.net (sccrmhc12) with SMTP
          id <20041104133913012009m473e>
          (Authid: sdawkins@comcast.net);
          Thu, 4 Nov 2004 13:39:13 +0000
Message-ID: <098301c4c273$c7e88af0$0200a8c0@DFNJGL21>
Reply-To: "Spencer Dawkins" <spencer@mcsr-labs.org>
From: "Spencer Dawkins" <spencer@mcsr-labs.org>
To: <v6ops@ops.ietf.org>
References: <BDAFBB19.4DD4A%jordi.palet@consulintel.es>
Subject: Re: A personal take on WG's priorities..
Date: Thu, 4 Nov 2004 07:39:59 -0600
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

FWIW, the SIP community has been reasonably effective in "dividing and 
conquoring" with at least SIP, SIPPING ("the kidney of the SIP 
community", to quote Dean Willis, and I don't know who said it first), 
XCON, SIMPLE, plus a few million ad hoc discussions.

My impression from the outside is that Jordi correctly points out the 
challenges:

- SIP and SIPPING share two out of three WG chairs, so coordination is 
tighter but the load on the chairs is heavier,

- Core specifications may be WGLCed in multiple WGs (SIP and SIPPING, 
for example), to make sure everyone is in the loop,

- Ideas that span WGs may bounce around a bit (conferencing framework, 
for example).

- if you can't spend the entire IETF in SIPpish meetings, you're just 
not trying.

I also note that at least some communities in the IETF can either work 
effectively on specifications or on a charter, but not both at once. 
Is v6ops one of these communities? If so, a charter tsunami would slow 
our work down before we accelerate.

Spencer, who is trying to find a nice way to ask David, "would you 
prefer to see multiple WGs, or multiple 'sub-WGs' within v6ops?"

From: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>
To: <v6ops@ops.ietf.org>
Sent: Thursday, November 04, 2004 3:55 AM
Subject: Re: A personal take on WG's priorities..


Hi Brian,

May be I'm wrong, but if the objective to outsource some of the work 
is to
"evacuate" it faster, I think is not the right way.

I mean, if they are within the charter, they are operational issues, 
pushing
it outside, will mean some of the people that is doing effort here, 
will
divide his time following up to WGs (at least), attending 2 meetings, 
etc.
At the end, some times this can be rather more time consuming that
proceeding here. I've this experience in projects, when you divide the 
work
in several WGs and then becomes fragmented, and the people, who is 
limited
in number and resources, availability, etc., tend to keep only with 
part of
the work, very concentrated and missing the overall picture.

Consequently, I will agree with this only in case we have extra 
effort,
which is not the case, but in general in IETF on the contrary. Less 
people
less effort with the time ..., unfortunately.

I will agree that if we have something that is clearly specific to an
existing WG, then it should be forwarded there. Similarly, if there is 
some
work that requires a very focused effort, then we should try to create 
a new
WG, probably.

Regards,
Jordi 





From owner-v6ops@ops.ietf.org  Thu Nov  4 08:42:44 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20194
	for <v6ops-archive@lists.ietf.org>; Thu, 4 Nov 2004 08:42:43 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CPhsi-000K6r-6E
	for v6ops-data@psg.com; Thu, 04 Nov 2004 13:42:28 +0000
Received: from [192.44.77.17] (helo=laposte.rennes.enst-bretagne.fr)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CPhsg-000K6V-VG
	for v6ops@ops.ietf.org; Thu, 04 Nov 2004 13:42:27 +0000
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194])
	by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id iA4DgJ609723;
	Thu, 4 Nov 2004 14:42:19 +0100
Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id iA4DgISj068519;
	Thu, 4 Nov 2004 14:42:19 +0100 (CET)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200411041342.iA4DgISj068519@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: "Inseok Choi" <ischl@cns.ssu.ac.kr>
cc: v6ops@ops.ietf.org
Subject: Re: IPsec support for NAT-PT in IPv6 
In-reply-to: Your message of Wed, 03 Nov 2004 20:18:33 +0900.
             <200411031118.iA3BImGO005938@coliposte.enst-bretagne.fr> 
Date: Thu, 04 Nov 2004 14:42:18 +0100
X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

 In your previous mail you wrote:

   * IKE ==> In environment which it use dynamic address(DHCP, NAT, ...), as
   possible as we use IKE using CERT. but IKE can't surely use CERT in
   condition (ex> no CERT, authentication of IP address).
   In real IKE procedure, I think we need to see things from various
   methodology.
   
=> you are simply trying to make NAT-PT an exceptional case: I disagree,
NAT traversal, "road warriors", etc, are already known and handled cases.

   * IPsec using UDP encapsulation in NAT-PT
   ==> If we use IPsec using UDP encapsulation, see below
   1. NAT ==> |New IPv4 header|UDP|Original IPv4 header|IKE or AH payload|

=> there is no such "Original IPv4 header" (IKE doesn't tunnel and
AH is usable in tunnel mode only in theory).

   2. NAT-PT ==> |New IPv4 header|UDP|Original IPv6 header|IKE of AH payload|
   
=> same.
The only problem is with ESP transport:

New IPv4 header|optional UDP|ESP {ESP header|Original IPv6 packet|ESP trailer}
where of course the Original IPv6 packet, likely encripted, can't be
understood by the IPv4 only peer. But NAT-PT can't do something,
this is just a service (ESP tunnel) which doesn't make any sense
in this context.

   NAT can use UDP encapsulation method because no change Original IPv4 header.
   and opposite peer can understand original IPv4 packet.
   But NAT-PT can't use same method because opposite peer can't understand
   original IPv6 packet.
   
=> please read NAT traversal and UDP encapsulation drafts...
      
Regards
      
Francis.Dupont@enst-bretagne.fr



From owner-v6ops@ops.ietf.org  Thu Nov  4 10:29:33 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00943
	for <v6ops-archive@lists.ietf.org>; Thu, 4 Nov 2004 10:29:32 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CPjWz-0006rO-25
	for v6ops-data@psg.com; Thu, 04 Nov 2004 15:28:09 +0000
Received: from [213.172.48.142] (helo=consulintel.es)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CPjWm-0006po-Ij
	for v6ops@ops.ietf.org; Thu, 04 Nov 2004 15:27:57 +0000
Received: from [141.39.27.12] ([141.39.27.12])
	by consulintel.es (consulintel.es [127.0.0.1])
	(MDaemon.PRO.v7.2.0.R)
	with ESMTP id md50000557695.msg
	for <v6ops@ops.ietf.org>; Thu, 04 Nov 2004 16:33:23 +0100
User-Agent: Microsoft-Entourage/10.1.4.030702.0
Date: Thu, 04 Nov 2004 15:56:23 +0100
Subject: Re: Tunnel Discovery
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: <v6ops@ops.ietf.org>
Message-ID: <BDB001A7.4DE80%jordi.palet@consulintel.es>
In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B07C4C4F1@tayexc13.americas.cpqcorp.net>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Spam-Processed: consulintel.es, Thu, 04 Nov 2004 16:33:23 +0100
	(not processed: message from valid local sender)
X-MDRemoteIP: 141.39.27.12
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ops.ietf.org
Reply-To: jordi.palet@consulintel.es
X-MDAV-Processed: consulintel.es, Thu, 04 Nov 2004 16:33:25 +0100
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Jim,

The idea behind those two works are to be complementary.

One specify the requirements for assisted tunneling, while the other one is
the result of the analysis document (draft-palet-v6ops-tun-auto-disc), to
specify how the TEP (used by different mechanisms, all those that do
tunneling), should be discovered.

We need to decide if this is applied only to TBs, for example (so the users
don't need to manually look for the TB via Google or whatever), or if is
applicable (or at least open) to be used also by other mechanisms.

Today most of the mechanism use a default TEP, but is not usually the best
one, and can be configured via a change in a configuration file, command
line, or whatever.

Our understanding is that it will be nice if the same mechanism, an
automatic one (that of course can be overridden), could be used by all the
mechanisms, and moreover, not requiring any modification of those
mechanisms, but being activated before the mechanisms itself.

We are working in documenting a little bit more this part, because is not
complete enough in the document right now. I hope we can have some new text
next week already.

For example, today only 6to4 does it, via anycast, but this is not the best
solution, as we know. That's why we decided to use DNS SRV RR, after
analyzing all the possible existing solutions (to avoid a new mechanism),
and anycast as a last resort backup (in case when the ISP doesn't provide
the service to their customers, they can still find some services available
outside, as today we do with 6to4, or simply if the ISP prefers to use
directly anycast instead of DNS SRV RR for whatever reason).

One more step is to document the usage of the same mechanism to discover not
only 6in4 TEPs, but also 4in6 ones, as we believe that will be nice (and
possible) to have a single one for any x-in-x encapsulation.

Regards,
Jordi

> De: "Bound, Jim" <jim.bound@hp.com>
> Responder a: owner-v6ops@ops.ietf.org
> Fecha: Thu, 4 Nov 2004 08:05:28 -0500
> Para: <v6ops@ops.ietf.org>
> Asunto: Tunnel Discovery
> 
> Appears to me we have a few specs doing tunnel endpoint discovery or
> automation of tunnels.  At this point I think we need to see if we need
> one document.  Two I reviewed are below:
> 
> draft-palet-v6ops-solution-tun-auto-disc-01.txt
> 
> The above has good uses cases but I am not clear DNS should be used in
> the manner suggested operationally.
> 
> draft-ietf-v6ops-assisted-tunneling-requirements-01.txt
> 
> The above is approaching the problem correctly and a good piece of work.
> And also a good vechicle to documet the various issues and opportunities
> for work.
> 
> Does the working group believe tunnel discovery is important to automate
> or have means to set up policy or do we leave to the market, given all
> other work we have to do?  I don't know right now?
> 
> /jim
> 
> 



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






From owner-v6ops@ops.ietf.org  Thu Nov  4 11:20:40 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06077
	for <v6ops-archive@lists.ietf.org>; Thu, 4 Nov 2004 11:20:40 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CPkKh-000DYd-Q9
	for v6ops-data@psg.com; Thu, 04 Nov 2004 16:19:31 +0000
Received: from [195.212.29.150] (helo=mtagate1.de.ibm.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CPkKg-000DYP-Dq
	for v6ops@ops.ietf.org; Thu, 04 Nov 2004 16:19:31 +0000
Received: from d12nrmr1707.megacenter.de.ibm.com (d12nrmr1707.megacenter.de.ibm.com [9.149.167.81])
	by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id iA4GJSEA167300;
	Thu, 4 Nov 2004 16:19:28 GMT
Received: from sihl.zurich.ibm.com (d12av01.megacenter.de.ibm.com [9.149.165.212])
	by d12nrmr1707.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iA4GJRYE075454;
	Thu, 4 Nov 2004 17:19:27 +0100
Received: from zurich.ibm.com (sig-9-145-254-101.de.ibm.com [9.145.254.101])
	by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id RAA63334;
	Thu, 4 Nov 2004 17:19:26 +0100
Message-ID: <418A568C.4060501@zurich.ibm.com>
Date: Thu, 04 Nov 2004 17:19:24 +0100
From: Brian E Carpenter <brc@zurich.ibm.com>
Organization: IBM
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en, fr, de
MIME-Version: 1.0
To: Sham Chakravorty <schakra@mitre.org>
CC: v6ops@ops.ietf.org
Subject: Flow Label [Re: A personal take on WG's priorities..]
References: <012c01c4c271$9d19c020$11181d80@MITRE.ORG>
In-Reply-To: <012c01c4c271$9d19c020$11181d80@MITRE.ORG>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Sham, the flow label is low on my personal priority list.
The reason I was eager to get RFC 3697 done is to set boundary
conditions on its use, but developing the actual use cases
seems to me to be off the critical path for the IETF.

Looking at your email address, I can see why you might give it
higher priority - but do you need the IETF for that right now,
as long as you obey RFC 3697?

     Brian

Sham Chakravorty wrote:
> In this regard, would it make sense to add IPv6 Flow Label usage in a
> "sub-WG" area such as Enterprise or IPv6 Traffic Modeling?  One would think
> this is one of the  key IPv6 operations areas.  It seems to me we are
> focused only in a few, narrowly focused areas of IPv6 operations (as
> reflected in the charter).
> 
> Sham Chakravorty
> 
> -----Original Message-----
> From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf
> Of EricLKlein
> Sent: Thursday, November 04, 2004 3:30 AM
> To: v6ops@ops.ietf.org
> Subject: Re: A personal take on WG's priorities..
> 
> 
> From: "Brian
> 
>>Quite obviously, it would be outrageous to attempt all this
>>in one WG. IMHO, we need to either out-source work to other
>>WGs or create several new WGs with focussed charters.
>>Especially, we need to separate "getting known stuff
>>fully operational" from "doing new stuff."
> 
> 
> Is it possible to try to set up "sub-WG" areas and recruit more specialized
> people into these areas?
> 
> I am thinking (of the top of my head) of three subgroups:
> - Enterprise - would include migration issues, etc.
> - ISPs - would handle tunnels, interconnections, etc
> - IPv6 Security - would handle NAT-PT, depreciating NAT in IPv6, etc.
> 
> Just a thought.
> Eric
> 
> 
> 
> 
> 
> 



From owner-v6ops@ops.ietf.org  Thu Nov  4 11:21:08 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06168
	for <v6ops-archive@lists.ietf.org>; Thu, 4 Nov 2004 11:21:07 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CPkM1-000Di5-RC
	for v6ops-data@psg.com; Thu, 04 Nov 2004 16:20:53 +0000
Received: from [195.212.29.150] (helo=mtagate1.de.ibm.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CPkLx-000Dhh-8X
	for v6ops@ops.ietf.org; Thu, 04 Nov 2004 16:20:49 +0000
Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1])
	by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id iA4GKjEA204540;
	Thu, 4 Nov 2004 16:20:45 GMT
Received: from sihl.zurich.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228])
	by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iA4GKi5I052262;
	Thu, 4 Nov 2004 17:20:44 +0100
Received: from zurich.ibm.com (sig-9-145-254-101.de.ibm.com [9.145.254.101])
	by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id RAA84366;
	Thu, 4 Nov 2004 17:20:43 +0100
Message-ID: <418A56D9.1040106@zurich.ibm.com>
Date: Thu, 04 Nov 2004 17:20:41 +0100
From: Brian E Carpenter <brc@zurich.ibm.com>
Organization: IBM
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en, fr, de
MIME-Version: 1.0
To: jordi.palet@consulintel.es
CC: v6ops@ops.ietf.org
Subject: Re: A personal take on WG's priorities..
References: <BDAFBB19.4DD4A%jordi.palet@consulintel.es>
In-Reply-To: <BDAFBB19.4DD4A%jordi.palet@consulintel.es>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit

Jordi,

It's Management 101. I don't think any WG with so many diverse
topics has a chance of making good progress. We need to divide
and conquer, IMHO.

    Brian

JORDI PALET MARTINEZ wrote:
> Hi Brian,
> 
> May be I'm wrong, but if the objective to outsource some of the work is to
> "evacuate" it faster, I think is not the right way.
> 
> I mean, if they are within the charter, they are operational issues, pushing
> it outside, will mean some of the people that is doing effort here, will
> divide his time following up to WGs (at least), attending 2 meetings, etc.
> At the end, some times this can be rather more time consuming that
> proceeding here. I've this experience in projects, when you divide the work
> in several WGs and then becomes fragmented, and the people, who is limited
> in number and resources, availability, etc., tend to keep only with part of
> the work, very concentrated and missing the overall picture.
> 
> Consequently, I will agree with this only in case we have extra effort,
> which is not the case, but in general in IETF on the contrary. Less people
> less effort with the time ..., unfortunately.
> 
> I will agree that if we have something that is clearly specific to an
> existing WG, then it should be forwarded there. Similarly, if there is some
> work that requires a very focused effort, then we should try to create a new
> WG, probably.
> 
> Regards,
> Jordi
> 
> 
> 
>>De: Brian E Carpenter <brc@zurich.ibm.com>
>>Organización: IBM
>>Responder a: owner-v6ops@ops.ietf.org
>>Fecha: Thu, 04 Nov 2004 09:09:44 +0100
>>Para: Pekka Savola <pekkas@netcore.fi>
>>CC: v6ops@ops.ietf.org
>>Asunto: Re: A personal take on WG's priorities..
>>
>>Pekka,
>>
>>Loosely speaking, this list seems OK to me personally.
>>
>>Quite obviously, it would be outrageous to attempt all this
>>in one WG. IMHO, we need to either out-source work to other
>>WGs or create several new WGs with focussed charters.
>>Especially, we need to separate "getting known stuff
>>fully operational" from "doing new stuff."
>>
>>  Brian
>>
>>Pekka Savola wrote:
>>
>>>Hi,
>>>
>>>Based on the discussion on what the WG should be doing, I cooked up my
>>>**personal** list of what I consider to be priorities, in some rough
>>>categories.  As you see, there's a *LOT* that falls under the WG
>>>charter, and there is no way we could work on even 1/3 or 1/4 of these
>>>at the same time.  So, there must be some priorization.
>>>
>>>I welcome comments especially if you think I've badly misprioritized
>>>document/work that relates to the v6ops charter.
>>>
>>>======
>>>
>>>The most important work
>>> - finish enterprise analysis
>>> - finish requirement(s) for tunneling
>>>    * to be able to decide whether existing solution(s) are sufficient
>>>      and if not, get started on specifying new ones
>>> - get started on mechanisms (somewhere else?) if needed/necessary
>>>
>>>Pretty darn important work
>>> - the last spin at 3GPP analysis doc, updated IMS scenario
>>> - better document the ISP's broadband transition scenarios
>>>    * draft-asadullah-v6ops-bb-deployment-scenarios-01
>>> - finish draft-ietf-v6ops-mech-v2
>>>    * waiting for feedback from the IESG telechat..
>>> - adopt and finish draft-tschofenig-v6ops-secure-tunnels-02.txt
>>>    * IESG requirement for draft-ietf-v6ops-mech-v2
>>> - figure what to do about the NAT-PT deprecation/analysis
>>>   *  draft-aoun-v6ops-natpt-deprecate
>>> - (techno-political) document for v4 NAT users
>>>   * draft-vandevelde-v6ops-nap
>>> - IPv6-on-by-default work, fixes need to be integrated in the IETF work
>>>   * draft-ietf-v6ops-onlinkassumption
>>>   * draft-ietf-v6ops-v6onbydefault
>>>   * etc.
>>>
>>>Important work
>>> - draft-ietf-v6ops-renumbering-procedure
>>>   * needs revision to address IESG comments
>>> - draft-palet-v6ops-tun-auto-disc
>>> - draft-chown-v6ops-vlan-usage
>>> - figuring out how to deal with Mobile IP transition issues
>>> - security overview of IPv6
>>>    * draft-savola-v6ops-security-overview
>>>
>>>Useful work
>>> - revising 6to4 spec to be clearer, etc.
>>> - draft-palet-v6ops-solution-tun-auto-disc
>>> - draft-chown-v6ops-renumber-thinkabout-00
>>> - draft-chown-v6ops-port-scanning-implications
>>>
>>>Difficult to say whether it has gained sufficient momentum, and/or
>>> whether this is the right place to do this
>>> - draft-palet-v6ops-auto-trans
>>> - draft-palet-v6ops-ipv6security
>>> - draft-vives-v6ops-ipv6-security-ps
>>> - draft-kondo-quarantine-overview-01.txt
>>>
>>>Not sure whether it should be published as RFC, or is sufficiently relevant
>>> - draft-chown-v6ops-campus-transition
>>> - draft-morelli-v6ops-ipv6-ix
>>>
>>
>>
> 
> 
> 
> **********************************
> 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.
> 
> 
> 
> 
> 



From owner-v6ops@ops.ietf.org  Thu Nov  4 12:51:01 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15891
	for <v6ops-archive@lists.ietf.org>; Thu, 4 Nov 2004 12:51:01 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CPljP-0000Hx-VL
	for v6ops-data@psg.com; Thu, 04 Nov 2004 17:49:07 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CPljL-0000HF-Lm
	for v6ops@ops.ietf.org; Thu, 04 Nov 2004 17:49:04 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id iA4Hmqj19711;
	Thu, 4 Nov 2004 19:48:53 +0200
Date: Thu, 4 Nov 2004 19:48:52 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: Brian E Carpenter <brc@zurich.ibm.com>
cc: Sham Chakravorty <schakra@mitre.org>, v6ops@ops.ietf.org
Subject: Re: Flow Label [Re: A personal take on WG's priorities..]
In-Reply-To: <418A568C.4060501@zurich.ibm.com>
Message-ID: <Pine.LNX.4.61.0411041944570.19465@netcore.fi>
References: <012c01c4c271$9d19c020$11181d80@MITRE.ORG> <418A568C.4060501@zurich.ibm.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

On Thu, 4 Nov 2004, Brian E Carpenter wrote:
> Sham, the flow label is low on my personal priority list.
> The reason I was eager to get RFC 3697 done is to set boundary
> conditions on its use, but developing the actual use cases
> seems to me to be off the critical path for the IETF.
>
> Looking at your email address, I can see why you might give it
> higher priority - but do you need the IETF for that right now,
> as long as you obey RFC 3697?

FWIW, my personal take --

It might possibly make sense to set up a mailing list on IPv6 flow 
label usage, try to solicit people to join it, propose and discuss 
various proposals... and depending on how it goes, try to run a BOF at 
the next meeting to gauge the real interest.

Even if there is not sufficient interest, I believe it's vital to 
success to get those people interested of the flow label together.

At the first stage, the product might not be an IETF standards track 
document, or even an IETF document -- e.g., an experimental RFC 
through RFC-editor developed based on the mailing list discussion, but 
that would be at least a basis for further work w/ flow label.

In other words, it's important to get those diffserv/qos geeks in the 
same list/room with IPv6 specialists and those who'd like to use flow 
label in new, innovative ways .. and see what happens.

IMHO, in any case, v6ops-like generic WGs are probably not a good 
place to get sufficient amount of interest & expertise together.

-- 
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 owner-v6ops@ops.ietf.org  Thu Nov  4 13:11:45 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17578
	for <v6ops-archive@lists.ietf.org>; Thu, 4 Nov 2004 13:11:45 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CPm4e-0003Da-7x
	for v6ops-data@psg.com; Thu, 04 Nov 2004 18:11:04 +0000
Received: from [161.114.64.104] (helo=zmamail04.zma.compaq.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CPm4c-0003D1-UR
	for v6ops@ops.ietf.org; Thu, 04 Nov 2004 18:11:03 +0000
Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186])
	by zmamail04.zma.compaq.com (Postfix) with ESMTP id 1B64052D1;
	Thu,  4 Nov 2004 13:11:02 -0500 (EST)
Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211);
	 Thu, 4 Nov 2004 13:11:01 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: A personal take on WG's priorities..
Date: Thu, 4 Nov 2004 13:10:57 -0500
Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B07C4C59D@tayexc13.americas.cpqcorp.net>
Thread-Topic: A personal take on WG's priorities..
Thread-Index: AcTCimA2H/uSxEy5Q16foNnVo/Gt/AADzD4w
From: "Bound, Jim" <jim.bound@hp.com>
To: "Brian E Carpenter" <brc@zurich.ibm.com>, <jordi.palet@consulintel.es>
Cc: <v6ops@ops.ietf.org>
X-OriginalArrivalTime: 04 Nov 2004 18:11:01.0906 (UTC) FILETIME=[A4832720:01C4C299]
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

But I don't agree we should not work on new emerging transition =
mechanisms that in fact are being deployed as we talk here.
/jim=20

> -----Original Message-----
> From: owner-v6ops@ops.ietf.org=20
> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Brian E Carpenter
> Sent: Thursday, November 04, 2004 11:21 AM
> To: jordi.palet@consulintel.es
> Cc: v6ops@ops.ietf.org
> Subject: Re: A personal take on WG's priorities..
>=20
> Jordi,
>=20
> It's Management 101. I don't think any WG with so many=20
> diverse topics has a chance of making good progress. We need=20
> to divide and conquer, IMHO.
>=20
>     Brian
>=20
> JORDI PALET MARTINEZ wrote:
> > Hi Brian,
> >=20
> > May be I'm wrong, but if the objective to outsource some of=20
> the work=20
> > is to "evacuate" it faster, I think is not the right way.
> >=20
> > I mean, if they are within the charter, they are=20
> operational issues,=20
> > pushing it outside, will mean some of the people that is=20
> doing effort=20
> > here, will divide his time following up to WGs (at least),=20
> attending 2 meetings, etc.
> > At the end, some times this can be rather more time consuming that=20
> > proceeding here. I've this experience in projects, when you=20
> divide the=20
> > work in several WGs and then becomes fragmented, and the=20
> people, who=20
> > is limited in number and resources, availability, etc.,=20
> tend to keep=20
> > only with part of the work, very concentrated and missing=20
> the overall picture.
> >=20
> > Consequently, I will agree with this only in case we have extra=20
> > effort, which is not the case, but in general in IETF on=20
> the contrary.=20
> > Less people less effort with the time ..., unfortunately.
> >=20
> > I will agree that if we have something that is clearly=20
> specific to an=20
> > existing WG, then it should be forwarded there. Similarly,=20
> if there is=20
> > some work that requires a very focused effort, then we=20
> should try to=20
> > create a new WG, probably.
> >=20
> > Regards,
> > Jordi
> >=20
> >=20
> >=20
> >>De: Brian E Carpenter <brc@zurich.ibm.com>
> >>Organizaci=F3n: IBM
> >>Responder a: owner-v6ops@ops.ietf.org
> >>Fecha: Thu, 04 Nov 2004 09:09:44 +0100
> >>Para: Pekka Savola <pekkas@netcore.fi>
> >>CC: v6ops@ops.ietf.org
> >>Asunto: Re: A personal take on WG's priorities..
> >>
> >>Pekka,
> >>
> >>Loosely speaking, this list seems OK to me personally.
> >>
> >>Quite obviously, it would be outrageous to attempt all this=20
> in one WG.=20
> >>IMHO, we need to either out-source work to other WGs or=20
> create several=20
> >>new WGs with focussed charters.
> >>Especially, we need to separate "getting known stuff fully=20
> >>operational" from "doing new stuff."
> >>
> >>  Brian
> >>
> >>Pekka Savola wrote:
> >>
> >>>Hi,
> >>>
> >>>Based on the discussion on what the WG should be doing, I=20
> cooked up=20
> >>>my
> >>>**personal** list of what I consider to be priorities, in=20
> some rough=20
> >>>categories.  As you see, there's a *LOT* that falls under the WG=20
> >>>charter, and there is no way we could work on even 1/3 or 1/4 of=20
> >>>these at the same time.  So, there must be some priorization.
> >>>
> >>>I welcome comments especially if you think I've badly=20
> misprioritized=20
> >>>document/work that relates to the v6ops charter.
> >>>
> >>>=3D=3D=3D=3D=3D=3D
> >>>
> >>>The most important work
> >>> - finish enterprise analysis
> >>> - finish requirement(s) for tunneling
> >>>    * to be able to decide whether existing solution(s)=20
> are sufficient
> >>>      and if not, get started on specifying new ones
> >>> - get started on mechanisms (somewhere else?) if needed/necessary
> >>>
> >>>Pretty darn important work
> >>> - the last spin at 3GPP analysis doc, updated IMS scenario
> >>> - better document the ISP's broadband transition scenarios
> >>>    * draft-asadullah-v6ops-bb-deployment-scenarios-01
> >>> - finish draft-ietf-v6ops-mech-v2
> >>>    * waiting for feedback from the IESG telechat..
> >>> - adopt and finish draft-tschofenig-v6ops-secure-tunnels-02.txt
> >>>    * IESG requirement for draft-ietf-v6ops-mech-v2
> >>> - figure what to do about the NAT-PT deprecation/analysis
> >>>   *  draft-aoun-v6ops-natpt-deprecate
> >>> - (techno-political) document for v4 NAT users
> >>>   * draft-vandevelde-v6ops-nap
> >>> - IPv6-on-by-default work, fixes need to be integrated in=20
> the IETF work
> >>>   * draft-ietf-v6ops-onlinkassumption
> >>>   * draft-ietf-v6ops-v6onbydefault
> >>>   * etc.
> >>>
> >>>Important work
> >>> - draft-ietf-v6ops-renumbering-procedure
> >>>   * needs revision to address IESG comments
> >>> - draft-palet-v6ops-tun-auto-disc
> >>> - draft-chown-v6ops-vlan-usage
> >>> - figuring out how to deal with Mobile IP transition issues
> >>> - security overview of IPv6
> >>>    * draft-savola-v6ops-security-overview
> >>>
> >>>Useful work
> >>> - revising 6to4 spec to be clearer, etc.
> >>> - draft-palet-v6ops-solution-tun-auto-disc
> >>> - draft-chown-v6ops-renumber-thinkabout-00
> >>> - draft-chown-v6ops-port-scanning-implications
> >>>
> >>>Difficult to say whether it has gained sufficient=20
> momentum, and/or =20
> >>>whether this is the right place to do this
> >>> - draft-palet-v6ops-auto-trans
> >>> - draft-palet-v6ops-ipv6security
> >>> - draft-vives-v6ops-ipv6-security-ps
> >>> - draft-kondo-quarantine-overview-01.txt
> >>>
> >>>Not sure whether it should be published as RFC, or is sufficiently=20
> >>>relevant
> >>> - draft-chown-v6ops-campus-transition
> >>> - draft-morelli-v6ops-ipv6-ix
> >>>
> >>
> >>
> >=20
> >=20
> >=20
> > **********************************
> > Madrid 2003 Global IPv6 Summit
> > Presentations and videos on line at:
> > http://www.ipv6-es.com
> >=20
> > This electronic message contains information which may be=20
> privileged or confidential. The information is intended to be=20
> for the use of the individual(s) named above. If you are not=20
> the intended recipient be aware that any disclosure, copying,=20
> distribution or use of the contents of this information,=20
> including attached files, is prohibited.
> >=20
> >=20
> >=20
> >=20
> >=20
>=20
>=20



From owner-v6ops@ops.ietf.org  Thu Nov  4 13:12:59 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17699
	for <v6ops-archive@lists.ietf.org>; Thu, 4 Nov 2004 13:12:58 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CPm6B-0003Nn-Bh
	for v6ops-data@psg.com; Thu, 04 Nov 2004 18:12:39 +0000
Received: from [161.114.64.103] (helo=zmamail03.zma.compaq.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CPm60-0003KT-Mz
	for v6ops@ops.ietf.org; Thu, 04 Nov 2004 18:12:28 +0000
Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186])
	by zmamail03.zma.compaq.com (Postfix) with ESMTP id 47B008C;
	Thu,  4 Nov 2004 13:12:28 -0500 (EST)
Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211);
	 Thu, 4 Nov 2004 13:12:28 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Flow Label [Re: A personal take on WG's priorities..]
Date: Thu, 4 Nov 2004 13:12:25 -0500
Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B07C4C59F@tayexc13.americas.cpqcorp.net>
Thread-Topic: Flow Label [Re: A personal take on WG's priorities..]
Thread-Index: AcTCimDCM9hCCDiBQRK8ZN7oshwQhQAD00ig
From: "Bound, Jim" <jim.bound@hp.com>
To: "Brian E Carpenter" <brc@zurich.ibm.com>,
        "Sham Chakravorty" <schakra@mitre.org>
Cc: <v6ops@ops.ietf.org>
X-OriginalArrivalTime: 04 Nov 2004 18:12:28.0093 (UTC) FILETIME=[D7E23ED0:01C4C299]
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

This is high on my list because it requires traffice engineering and not
clear why Brian would suggest that Mitre or those clients are the only
needs right now for this work because there are many others.  Nor should
that affect what we work on.
/jim=20

> -----Original Message-----
> From: owner-v6ops@ops.ietf.org=20
> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Brian E Carpenter
> Sent: Thursday, November 04, 2004 11:19 AM
> To: Sham Chakravorty
> Cc: v6ops@ops.ietf.org
> Subject: Flow Label [Re: A personal take on WG's priorities..]
>=20
> Sham, the flow label is low on my personal priority list.
> The reason I was eager to get RFC 3697 done is to set=20
> boundary conditions on its use, but developing the actual use=20
> cases seems to me to be off the critical path for the IETF.
>=20
> Looking at your email address, I can see why you might give=20
> it higher priority - but do you need the IETF for that right=20
> now, as long as you obey RFC 3697?
>=20
>      Brian
>=20
> Sham Chakravorty wrote:
> > In this regard, would it make sense to add IPv6 Flow Label=20
> usage in a=20
> > "sub-WG" area such as Enterprise or IPv6 Traffic Modeling? =20
> One would=20
> > think this is one of the  key IPv6 operations areas.  It=20
> seems to me=20
> > we are focused only in a few, narrowly focused areas of IPv6=20
> > operations (as reflected in the charter).
> >=20
> > Sham Chakravorty
> >=20
> > -----Original Message-----
> > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On=20
> > Behalf Of EricLKlein
> > Sent: Thursday, November 04, 2004 3:30 AM
> > To: v6ops@ops.ietf.org
> > Subject: Re: A personal take on WG's priorities..
> >=20
> >=20
> > From: "Brian
> >=20
> >>Quite obviously, it would be outrageous to attempt all this=20
> in one WG.=20
> >>IMHO, we need to either out-source work to other WGs or=20
> create several=20
> >>new WGs with focussed charters.
> >>Especially, we need to separate "getting known stuff fully=20
> >>operational" from "doing new stuff."
> >=20
> >=20
> > Is it possible to try to set up "sub-WG" areas and recruit more=20
> > specialized people into these areas?
> >=20
> > I am thinking (of the top of my head) of three subgroups:
> > - Enterprise - would include migration issues, etc.
> > - ISPs - would handle tunnels, interconnections, etc
> > - IPv6 Security - would handle NAT-PT, depreciating NAT in=20
> IPv6, etc.
> >=20
> > Just a thought.
> > Eric
> >=20
> >=20
> >=20
> >=20
> >=20
> >=20
>=20
>=20



From owner-v6ops@ops.ietf.org  Thu Nov  4 13:34:33 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19889
	for <v6ops-archive@lists.ietf.org>; Thu, 4 Nov 2004 13:34:33 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CPmQo-0006dH-Ne
	for v6ops-data@psg.com; Thu, 04 Nov 2004 18:33:58 +0000
Received: from [192.18.98.36] (helo=brmea-mail-4.sun.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CPmQe-0006cS-9k
	for v6ops@ops.ietf.org; Thu, 04 Nov 2004 18:33:48 +0000
Received: from esunmail ([129.147.156.34])
	by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id iA4IXlNH010352
	for <v6ops@ops.ietf.org>; Thu, 4 Nov 2004 11:33:47 -0700 (MST)
Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM
 (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTP id <0I6O00LSJ3KA7N@edgemail1.Central.Sun.COM> for
 v6ops@ops.ietf.org; Thu, 04 Nov 2004 11:33:47 -0700 (MST)
Received: from [192.168.1.102] ([66.93.39.75])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I6O00LT23K9OZ@mail.sun.net> for v6ops@ops.ietf.org; Thu,
 04 Nov 2004 11:33:46 -0700 (MST)
Date: Thu, 04 Nov 2004 10:35:25 -0800
From: Alain Durand <Alain.Durand@Sun.COM>
Subject: Re: Tunnel Discovery
In-reply-to: 
 <9C422444DE99BC46B3AD3C6EAFC9711B07C4C4F1@tayexc13.americas.cpqcorp.net>
To: "Bound, Jim" <jim.bound@hp.com>
Cc: v6ops@ops.ietf.org
Message-id: <418A766D.5080308@sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20040906
References: 
 <9C422444DE99BC46B3AD3C6EAFC9711B07C4C4F1@tayexc13.americas.cpqcorp.net>
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7BIT

Bound, Jim wrote:

>Appears to me we have a few specs doing tunnel endpoint discovery or
>automation of tunnels.  At this point I think we need to see if we need
>one document.  Two I reviewed are below:
>
>draft-palet-v6ops-solution-tun-auto-disc-01.txt
>
>The above has good uses cases but I am not clear DNS should be used in
>the manner suggested operationally.
>  
>

There is also:
http://www.ietf.org/internet-drafts/draft-yamamoto-naptr-service-discovery-00.txt

>draft-ietf-v6ops-assisted-tunneling-requirements-01.txt
>
>The above is approaching the problem correctly and a good piece of work.
>And also a good vechicle to documet the various issues and opportunities
>for work.
>  
>
This one is a requirement document, not a solution one..

>Does the working group believe tunnel discovery is important to automate
>or have means to set up policy or do we leave to the market, given all
>other work we have to do?  I don't know right now?
>  
>
IMHO, this is/should be on the critical path of this wg.

    - Alain.



From owner-v6ops@ops.ietf.org  Thu Nov  4 13:45:23 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20699
	for <v6ops-archive@lists.ietf.org>; Thu, 4 Nov 2004 13:45:23 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CPmbH-0008HR-Eo
	for v6ops-data@psg.com; Thu, 04 Nov 2004 18:44:47 +0000
Received: from [192.160.51.76] (helo=smtp-bedford.mitre.org)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CPmb6-0008D9-LK
	for v6ops@ops.ietf.org; Thu, 04 Nov 2004 18:44:36 +0000
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1])
	by smtp-bedford.mitre.org (8.11.6/8.11.6) with SMTP id iA4Iiah08509
	for <v6ops@ops.ietf.org>; Thu, 4 Nov 2004 13:44:36 -0500
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1])
	by smtp-bedford.mitre.org (Postfix) with ESMTP id D5FD3BF7D
	for <v6ops@ops.ietf.org>; Thu,  4 Nov 2004 13:44:35 -0500 (EST)
Received: from MAILHUB1 (mailhub1.mitre.org [129.83.20.31])
	by smtp-bedford.mitre.org (8.11.6/8.11.6) with ESMTP id iA4IiZI08419;
	Thu, 4 Nov 2004 13:44:35 -0500
Received: from mm113749-pc.mitre.org (128.29.24.17) by mailhub1.mitre.org with SMTP
        id 10470336; Thu, 04 Nov 2004 13:44:30 -0500
From: "Sham Chakravorty" <schakra@mitre.org>
To: "'Bound, Jim'" <jim.bound@hp.com>,
        "'Brian E Carpenter'" <brc@zurich.ibm.com>
Cc: <v6ops@ops.ietf.org>
Subject: RE: Flow Label [Re: A personal take on WG's priorities..]
Date: Thu, 4 Nov 2004 13:44:28 -0500
Message-ID: <01be01c4c29e$506f4fb0$11181d80@MITRE.ORG>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
In-reply-to: <9C422444DE99BC46B3AD3C6EAFC9711B07C4C59F@tayexc13.americas.cpqcorp.net>
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Importance: Normal
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

I agree with Jim.  

Sham


-----Original Message-----
From: Bound, Jim [mailto:jim.bound@hp.com] 
Sent: Thursday, November 04, 2004 1:12 PM
To: Brian E Carpenter; Sham Chakravorty
Cc: v6ops@ops.ietf.org
Subject: RE: Flow Label [Re: A personal take on WG's priorities..]


This is high on my list because it requires traffice engineering and not
clear why Brian would suggest that Mitre or those clients are the only
needs right now for this work because there are many others.  Nor should
that affect what we work on.
/jim 

> -----Original Message-----
> From: owner-v6ops@ops.ietf.org 
> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Brian E Carpenter
> Sent: Thursday, November 04, 2004 11:19 AM
> To: Sham Chakravorty
> Cc: v6ops@ops.ietf.org
> Subject: Flow Label [Re: A personal take on WG's priorities..]
> 
> Sham, the flow label is low on my personal priority list.
> The reason I was eager to get RFC 3697 done is to set 
> boundary conditions on its use, but developing the actual use 
> cases seems to me to be off the critical path for the IETF.
> 
> Looking at your email address, I can see why you might give 
> it higher priority - but do you need the IETF for that right 
> now, as long as you obey RFC 3697?
> 
>      Brian
> 
> Sham Chakravorty wrote:
> > In this regard, would it make sense to add IPv6 Flow Label 
> usage in a 
> > "sub-WG" area such as Enterprise or IPv6 Traffic Modeling?  
> One would 
> > think this is one of the  key IPv6 operations areas.  It 
> seems to me 
> > we are focused only in a few, narrowly focused areas of IPv6 
> > operations (as reflected in the charter).
> > 
> > Sham Chakravorty
> > 
> > -----Original Message-----
> > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On 
> > Behalf Of EricLKlein
> > Sent: Thursday, November 04, 2004 3:30 AM
> > To: v6ops@ops.ietf.org
> > Subject: Re: A personal take on WG's priorities..
> > 
> > 
> > From: "Brian
> > 
> >>Quite obviously, it would be outrageous to attempt all this 
> in one WG. 
> >>IMHO, we need to either out-source work to other WGs or 
> create several 
> >>new WGs with focussed charters.
> >>Especially, we need to separate "getting known stuff fully 
> >>operational" from "doing new stuff."
> > 
> > 
> > Is it possible to try to set up "sub-WG" areas and recruit more 
> > specialized people into these areas?
> > 
> > I am thinking (of the top of my head) of three subgroups:
> > - Enterprise - would include migration issues, etc.
> > - ISPs - would handle tunnels, interconnections, etc
> > - IPv6 Security - would handle NAT-PT, depreciating NAT in 
> IPv6, etc.
> > 
> > Just a thought.
> > Eric
> > 
> > 
> > 
> > 
> > 
> > 
> 
> 





From owner-v6ops@ops.ietf.org  Thu Nov  4 13:46:26 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20777
	for <v6ops-archive@lists.ietf.org>; Thu, 4 Nov 2004 13:46:25 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CPmcg-0008Qn-KW
	for v6ops-data@psg.com; Thu, 04 Nov 2004 18:46:14 +0000
Received: from [192.160.51.76] (helo=smtp-bedford.mitre.org)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CPmcZ-0008Pm-Bz
	for v6ops@ops.ietf.org; Thu, 04 Nov 2004 18:46:07 +0000
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1])
	by smtp-bedford.mitre.org (8.11.6/8.11.6) with SMTP id iA4Ik6h16120
	for <v6ops@ops.ietf.org>; Thu, 4 Nov 2004 13:46:06 -0500
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1])
	by smtp-bedford.mitre.org (Postfix) with ESMTP id 202CEBF85
	for <v6ops@ops.ietf.org>; Thu,  4 Nov 2004 13:46:06 -0500 (EST)
Received: from MAILHUB1 (mailhub1.mitre.org [129.83.20.31])
	by smtp-bedford.mitre.org (8.11.6/8.11.6) with ESMTP id iA4Ik5I15999;
	Thu, 4 Nov 2004 13:46:05 -0500
Received: from mm113749-pc.mitre.org (128.29.24.17) by mailhub1.mitre.org with SMTP
        id 10470386; Thu, 04 Nov 2004 13:45:56 -0500
From: "Sham Chakravorty" <schakra@mitre.org>
To: "'Pekka Savola'" <pekkas@netcore.fi>
Cc: <v6ops@ops.ietf.org>
Subject: RE: Flow Label [Re: A personal take on WG's priorities..]
Date: Thu, 4 Nov 2004 13:45:54 -0500
Message-ID: <01bf01c4c29e$84009af0$11181d80@MITRE.ORG>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
In-reply-to: <Pine.LNX.4.61.0411041944570.19465@netcore.fi>
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Importance: Normal
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Pekka, 

We have plans similar to what you suggest.  But I sincerely believe that
your WG is the place for Flow Label discussion.  If resources don't allow
such added work, then that's something that needs to be pursued.

Sham

-----Original Message-----
From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf
Of Pekka Savola
Sent: Thursday, November 04, 2004 12:49 PM
To: Brian E Carpenter
Cc: Sham Chakravorty; v6ops@ops.ietf.org
Subject: Re: Flow Label [Re: A personal take on WG's priorities..]


On Thu, 4 Nov 2004, Brian E Carpenter wrote:
> Sham, the flow label is low on my personal priority list.
> The reason I was eager to get RFC 3697 done is to set boundary
> conditions on its use, but developing the actual use cases
> seems to me to be off the critical path for the IETF.
>
> Looking at your email address, I can see why you might give it
> higher priority - but do you need the IETF for that right now,
> as long as you obey RFC 3697?

FWIW, my personal take --

It might possibly make sense to set up a mailing list on IPv6 flow 
label usage, try to solicit people to join it, propose and discuss 
various proposals... and depending on how it goes, try to run a BOF at 
the next meeting to gauge the real interest.

Even if there is not sufficient interest, I believe it's vital to 
success to get those people interested of the flow label together.

At the first stage, the product might not be an IETF standards track 
document, or even an IETF document -- e.g., an experimental RFC 
through RFC-editor developed based on the mailing list discussion, but 
that would be at least a basis for further work w/ flow label.

In other words, it's important to get those diffserv/qos geeks in the 
same list/room with IPv6 specialists and those who'd like to use flow 
label in new, innovative ways .. and see what happens.

IMHO, in any case, v6ops-like generic WGs are probably not a good 
place to get sufficient amount of interest & expertise together.

-- 
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 owner-v6ops@ops.ietf.org  Thu Nov  4 14:08:03 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22863
	for <v6ops-archive@lists.ietf.org>; Thu, 4 Nov 2004 14:08:02 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CPmwT-000BTe-3e
	for v6ops-data@psg.com; Thu, 04 Nov 2004 19:06:41 +0000
Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CPmwL-000BRf-QF
	for v6ops@ops.ietf.org; Thu, 04 Nov 2004 19:06:34 +0000
Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131])
	by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id iA4J6WGn005260
	for <v6ops@ops.ietf.org>; Thu, 4 Nov 2004 19:06:32 GMT
Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162])
	by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id TAA29571
	for <v6ops@ops.ietf.org>; Thu, 4 Nov 2004 19:06:27 GMT
Received: (from tjc@localhost)
	by login.ecs.soton.ac.uk (8.11.6/8.11.6) id iA4J6Rc03544
	for v6ops@ops.ietf.org; Thu, 4 Nov 2004 19:06:27 GMT
Date: Thu, 4 Nov 2004 19:06:27 +0000
From: Tim Chown <tjc@ecs.soton.ac.uk>
To: v6ops@ops.ietf.org
Subject: Re: Next steps
Message-ID: <20041104190627.GT1480@login.ecs.soton.ac.uk>
Mail-Followup-To: v6ops@ops.ietf.org
References: <BDAEF77F.4DB4A%jordi.palet@consulintel.es> <p0602046dbdaeefd531a9@[192.168.2.2]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <p0602046dbdaeefd531a9@[192.168.2.2]>
User-Agent: Mutt/1.4i
X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information
X-ECS-MailScanner: Found to be clean
X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

On Wed, Nov 03, 2004 at 03:33:15PM -0500, Margaret Wasserman wrote:
> 
> For instance, I think that we could do some valuable work studying 
> the security implications of running a dual-stack enterprise network 
> and documenting some operational best practices for that type of 
> deployment.

I think this is a very important one.  It's something we're doing very
actively at my site, looking at firewalling, IDS, transition and many other
aspects.   We have IPv6 pervasively on the wire, and many services enabled,
and issues do frequently get thrown up.   It's a big area, indeed you could
argue that IPv6 Enterprise transition could be a WG of its own(!) with 
everything there is to cover.  

It's also important to push out what we can to existing WGs to get v6 
considered (not to the point of a "IPv6 Considerations" in every I-D of 
course) but the wider the coverage the better we're placed, I feel.
 
> I'd also like to see us engage some the early IPv6 ISP-type operators 
> (Japanese ISPs, the 6Net folks, Internet 2, etc.) and discuss their 
> experiences, particularly an operational problems that they have 
> experienced.

So what specifically do you want to know?   In the case of 6NET it has
8 months to run, and thus any guidance for documentation would be welcome,
beit from the NREN/ISP perspective or the university/enterprise.  What do
you want to see?

Tim



From owner-v6ops@ops.ietf.org  Thu Nov  4 14:08:23 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22882
	for <v6ops-archive@lists.ietf.org>; Thu, 4 Nov 2004 14:08:22 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CPmxk-000BgB-AG
	for v6ops-data@psg.com; Thu, 04 Nov 2004 19:08:00 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CPmxN-000BcB-Mn
	for v6ops@ops.ietf.org; Thu, 04 Nov 2004 19:07:38 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id iA4J7X021553;
	Thu, 4 Nov 2004 21:07:33 +0200
Date: Thu, 4 Nov 2004 21:07:33 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
cc: v6ops@ops.ietf.org
Subject: Re: A personal take on WG's priorities..
In-Reply-To: <BDAFC159.4DD4D%jordi.palet@consulintel.es>
Message-ID: <Pine.LNX.4.61.0411042029200.20621@netcore.fi>
References: <BDAFC159.4DD4D%jordi.palet@consulintel.es>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

On Thu, 4 Nov 2004, JORDI PALET MARTINEZ wrote:
> Group 1
>> The most important work
>> - finish enterprise analysis
>> - finish requirement(s) for tunneling
>>    * to be able to decide whether existing solution(s) are sufficient
>>      and if not, get started on specifying new ones
>> - get started on mechanisms (somewhere else?) if needed/necessary
>
> I will say that is not good that a new WG should take care of new mechanisms
> (if they are required). This will slow down the process too much (minimum 6
> months), and it not clear that we can't do that with the current charter, or
> even a small modification of it.

Yes, there are challenges with spinning up a new WG, but it does not 
necessarily need to take that long, and the work doesn't have to be 
stalled during the time it takes to officially kick-start a WG.

Putting all the work relating to protocols certainly seems to be a 
relatively easily separable piece of the current charter.

Now, if we take those items from the list which might be 
protocol-related, we have:

  - finish requirement(s) for tunneling
  - get started on mechanisms (somewhere else?) if needed/necessary
  - finish draft-ietf-v6ops-mech-v2
  - adopt and finish draft-tschofenig-v6ops-secure-tunnels-02.txt
  - draft-palet-v6ops-tun-auto-disc
  - revising 6to4 spec to be clearer, etc.
  - draft-palet-v6ops-solution-tun-auto-disc
  - draft-palet-v6ops-auto-trans

That seems a close-to-manageable list, keeping in mind that mech-v2 is 
pretty much complete in any case.  That would allow v6ops WG to better 
focus on non-protocol work items, also those you wanted to be 
addressing.

For the rest of the items, see a possible division at the end..

> Also, I think this
>> - draft-palet-v6ops-tun-auto-disc
> belongs to what I called Group 1, and is ready to be closed. Otherwise will
> be good the received inputs, objections or whatever !

I don't disagree that this is rather close to being closed, but the 
question is of its urgency -- I think it'll be needed only when we 
start figuring out which kind of protocols we specify, or how we 
modify them.  (Granted, it would be useful if there was already 
consensus on that then.)

> Group 2
>> Pretty darn important work
>> - the last spin at 3GPP analysis doc, updated IMS scenario
>> - better document the ISP's broadband transition scenarios
>>    * draft-asadullah-v6ops-bb-deployment-scenarios-01
>> - finish draft-ietf-v6ops-mech-v2
>>    * waiting for feedback from the IESG telechat..
>> - adopt and finish draft-tschofenig-v6ops-secure-tunnels-02.txt
>>    * IESG requirement for draft-ietf-v6ops-mech-v2
>> - figure what to do about the NAT-PT deprecation/analysis
>>   *  draft-aoun-v6ops-natpt-deprecate
>> - (techno-political) document for v4 NAT users
>>   * draft-vandevelde-v6ops-nap
>> - IPv6-on-by-default work, fixes need to be integrated in the IETF work
>>   * draft-ietf-v6ops-onlinkassumption
>>   * draft-ietf-v6ops-v6onbydefault
>>   * etc.
>
> I think
>> - draft-palet-v6ops-solution-tun-auto-disc
> belongs to this group, and is 80% ready. Is very useful for the zeroconfig,
> assisted tunneling, etc.

As for draft-palet-v6ops-tun-auto-disc, this seems to be needed only 
after a little bit, certainly not before the requirements document is 
moving forward.

Personally, I think this is very far from done.  I think the approach 
has serious issues relating to the need to implement a lot of 
different functions.  Of course, these could be worked out as a WG 
item as well, but being technically sound gives more weight in the 
decision for WG adoption.

> I'm tempted to move all this to the Group 2 or 3, together with the
> security-overview. If this work needs to specify new protocols, then I might
> consider another WG (existing probably, not necessarily a new one), but I
> believe it can be approached with existing protocols within IETF.
> I consider security an extremely important issue for the deployment of IPv6,
> as an operational issue that falls clearly in the scope of our charter.
>
> By the way, I don't think is a question of momentum, is a question of people
> reviewing, and we all know that the problem is the same with other very
> important documents, which at the end pass by "no objection" despite Jim
> observations ! Let's be honest with ourselves, please ! I think is very
> stupid to try to convince ourselves about what is so evident. And yes is my
> own fault also, I will like to do more work review more documents, but
> specially the last 3-4 months has been almost impossible. Now I've plenty of
> time during Xmas and will do much more.

Let me explain why I raised the need for 'momentum'.  The IETF should 
not (IMHO) work at protocols or approaches if there isn't sufficient 
'buy-in' from the associated parties (e.g., the most important vendors 
which are required to make it successful, operators willing to deploy 
the stuff, enough people interested in the specification and reviewing 
etc.).

We (IMHO) should not move forward and put out RFCs on something, even 
if some deem that important, unless there is sufficient interest in 
the work so that the work would actually be used.  The result would 
probably be 1) irrelevant work that no-one will use, and/or 2) badly 
reviewed, technically unsound work, because there was not sufficient 
attention to the work.

I think the work on distributed security is one example of this.  The 
work needs to get attention from the different players in the field, 
most importantly the security folks (who were involved in defcon), 
some vendors (like Microsoft and Cisco, who have been working on a 
proprietary solution AFAIR), etc.  -- this work seems best suited to a 
separate mailing-list, with a BOF process, etc.  A separate mailing 
list seems like the only way to get focused attention on the work: 
security etc. folks would find the v6ops list too noisy.

> Group 6
>> Not sure whether it should be published as RFC, or is sufficiently relevant
>> - draft-chown-v6ops-campus-transition
>> - draft-morelli-v6ops-ipv6-ix
>
> Not sure either, but I will say is part of the scenarios documents.

Campus transition, yes -- if Tim and others think it's worth 
publishing.

IPv6-IX, not really, as that isn't the real operational model how 
(IPv6) exchanges are run.

> My conclusion is that we will have probably only 3 groups instead of 6,
> which can proceed almost in parallel, even if takes a few extra months
> (3-6), because that will be the same delay it will take creating a new WG,
> or even outsourcing to existing ones.

But these categories total like 25 documents!

As Brian said, there's no chance to work on those in parallel.  There 
_must_ be some serialization, or forking off to separate efforts. 
For example, 4-7 work items at the same time _might_ be doable, but 
some would say that even that much is a lot.

....

At the start I described some potential items for "v6mechs" WG.  Let's 
look a bit at a possible division of the rest:

Might be doable under v6ops (the middle category docs are almost done 
already, so there's only little work)
  - finish enterprise analysis
  - better document the ISP's broadband transition scenarios

  - the last spin at 3GPP analysis doc, updated IMS scenario
  - IPv6-on-by-default work, fixes need to be integrated in the IETF
  - draft-ietf-v6ops-renumbering-procedure
  - draft-chown-v6ops-vlan-usage

  - figure what to do about the NAT-PT deprecation/analysis
  - (techno-political) document for v4 NAT users
  - security overview of IPv6
  - draft-chown-v6ops-port-scanning-implications

Might be best to run through a separate mailing lists/BOFs process, 
(possibly fold back the results to v6ops when done there):

  - figuring out how to deal with Mobile IP transition issues
  - distributed security stuff
  - draft-chown-v6ops-renumber-thinkabout-00 (maybe)
  - maybe the ipv6 flow label applicability stuff

So, provided that some work that touches multiple areas, or areas of 
expertise could be run through a separate process, the load on v6ops 
might become manageable, and it would be more realistic to think about 
taking new _operational_ work items 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 owner-v6ops@ops.ietf.org  Thu Nov  4 14:22:56 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24210
	for <v6ops-archive@lists.ietf.org>; Thu, 4 Nov 2004 14:22:56 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CPnBd-000DUE-Cc
	for v6ops-data@psg.com; Thu, 04 Nov 2004 19:22:21 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CPnBc-000DTr-6R
	for v6ops@ops.ietf.org; Thu, 04 Nov 2004 19:22:20 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id iA4JMJX21886
	for <v6ops@ops.ietf.org>; Thu, 4 Nov 2004 21:22:19 +0200
Date: Thu, 4 Nov 2004 21:22:19 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: v6ops@ops.ietf.org
Subject: Re: WG last call on tunneling scenarios
In-Reply-To: <Pine.LNX.4.61.0411031922180.19604@netcore.fi>
Message-ID: <Pine.LNX.4.61.0411042121230.21829@netcore.fi>
References: <Pine.LNX.4.61.0410291149220.9900@netcore.fi> <20041030040506.GA3476@nokia.com>
 <Pine.LNX.4.61.0410300932370.7022@netcore.fi> <Pine.LNX.4.61.0411031922180.19604@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

For those who already deleted the email with the pointers, here they 
are again:

http://www.ietf.org/internet-drafts/draft-nielsen-v6ops-3GPP-zeroconf-goals-00.txt
http://www.v6ops.euro6ix.net/ietf/draft-suryanarayanan-v6ops-zeroconf-reqs-01.txt
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-assisted-tunneling-requirements-01.txt


On Wed, 3 Nov 2004, Pekka Savola wrote:
> On Sat, 30 Oct 2004, Pekka Savola wrote:
>> Fair enough.  Please send the objections (if any) on document adoption by 
>> the end of Tuesday 2nd November at the latest.
>> 
>> Comments/review on the drafts themselves are still welcome!
>
> (hat on)
>
> As there were no specific objections to adopting these documents, there 
> appears to be rough consensus on taking these as WG items.
>
> Let's continue the WG last call as called out earlier.
>
> *** We really need the reviews, and that means *YOU* too! :) ***
>
> (hat off)
>

-- 
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 owner-v6ops@ops.ietf.org  Thu Nov  4 14:25:02 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24490
	for <v6ops-archive@lists.ietf.org>; Thu, 4 Nov 2004 14:25:01 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CPnDr-000DnE-Qr
	for v6ops-data@psg.com; Thu, 04 Nov 2004 19:24:39 +0000
Received: from [161.114.64.105] (helo=zmamail05.zma.compaq.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CPnDn-000DmU-Ub
	for v6ops@ops.ietf.org; Thu, 04 Nov 2004 19:24:36 +0000
Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186])
	by zmamail05.zma.compaq.com (Postfix) with ESMTP id 988D4699C
	for <v6ops@ops.ietf.org>; Thu,  4 Nov 2004 14:24:35 -0500 (EST)
Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211);
	 Thu, 4 Nov 2004 14:24:35 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: Comments: draft-nielsen-v6ops-3GPP-zeroconf-goals-00.txt
Date: Thu, 4 Nov 2004 14:23:55 -0500
Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B07C4C5C0@tayexc13.americas.cpqcorp.net>
Thread-Topic: Comments: draft-nielsen-v6ops-3GPP-zeroconf-goals-00.txt
Thread-Index: AcTAHDhtaE25OJi3Tz2ikyL2oaJ6vwChn2vg
From: "Bound, Jim" <jim.bound@hp.com>
To: <v6ops@ops.ietf.org>
X-OriginalArrivalTime: 04 Nov 2004 19:24:35.0397 (UTC) FILETIME=[EB286F50:01C4C2A3]
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

The spec once it speaks about tunneling is all over the place saying it
can support private addresses, NATs etc.

http://www.ietf.org/internet-drafts/draft-nielsen-v6ops-3GPP-zeroconf-go
als-00.txt

I think some of this is just impossible for mobility.  A real case in
S.E. Asia right now looking at 3G IPv6 deployment has the following
problem.  Mobile (seamless) nodes will use native IPv6 and IPv4 to get
to legacy apps that have not been ported to IPv6.  In this case the
problem is that public IPv4 addresses are needed.  But we know all that
and we must address that case.  The other case is that to get to the IMS
networks first you havce to tunnel the packet through IPv4 network to
IMS IPv6 network.  This is not going to work with NAT when the user is
roaming.  So I don't see why the spec does not say this.

Hence, my first input to this spec (and I do believe it should be WG
item) is that we will need to discuss deployment profiles for mobility
and more of enterprise nature than 3GPP nature. =20

Thanks
/jim




From owner-v6ops@ops.ietf.org  Thu Nov  4 14:27:47 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24771
	for <v6ops-archive@lists.ietf.org>; Thu, 4 Nov 2004 14:27:46 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CPnGS-000EBq-BL
	for v6ops-data@psg.com; Thu, 04 Nov 2004 19:27:20 +0000
Received: from [195.212.29.137] (helo=mtagate4.uk.ibm.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CPnGR-000EBM-1Q
	for v6ops@ops.ietf.org; Thu, 04 Nov 2004 19:27:19 +0000
Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185])
	by mtagate4.uk.ibm.com (8.12.10/8.12.10) with ESMTP id iA4JRAIA227086;
	Thu, 4 Nov 2004 19:27:10 GMT
Received: from sihl.zurich.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216])
	by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iA4JR9DD063860;
	Thu, 4 Nov 2004 19:27:10 GMT
Received: from zurich.ibm.com (sig-9-146-220-75.de.ibm.com [9.146.220.75])
	by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id UAA14182;
	Thu, 4 Nov 2004 20:27:08 +0100
Message-ID: <418A828A.5070700@zurich.ibm.com>
Date: Thu, 04 Nov 2004 20:27:06 +0100
From: Brian E Carpenter <brc@zurich.ibm.com>
Organization: IBM
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en, fr, de
MIME-Version: 1.0
To: Sham Chakravorty <schakra@mitre.org>
CC: "'Pekka Savola'" <pekkas@netcore.fi>, v6ops@ops.ietf.org
Subject: Re: Flow Label [Re: A personal take on WG's priorities..]
References: <01bf01c4c29e$84009af0$11181d80@MITRE.ORG>
In-Reply-To: <01bf01c4c29e$84009af0$11181d80@MITRE.ORG>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

I like Pekka's idea to aim at a BOF at the following
IETF. But I really think this should be handled quite separately
from v6ops. It's a WG on its own.

   Brian

Sham Chakravorty wrote:
> Pekka, 
> 
> We have plans similar to what you suggest.  But I sincerely believe that
> your WG is the place for Flow Label discussion.  If resources don't allow
> such added work, then that's something that needs to be pursued.
> 
> Sham
> 
> -----Original Message-----
> From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf
> Of Pekka Savola
> Sent: Thursday, November 04, 2004 12:49 PM
> To: Brian E Carpenter
> Cc: Sham Chakravorty; v6ops@ops.ietf.org
> Subject: Re: Flow Label [Re: A personal take on WG's priorities..]
> 
> 
> On Thu, 4 Nov 2004, Brian E Carpenter wrote:
> 
>>Sham, the flow label is low on my personal priority list.
>>The reason I was eager to get RFC 3697 done is to set boundary
>>conditions on its use, but developing the actual use cases
>>seems to me to be off the critical path for the IETF.
>>
>>Looking at your email address, I can see why you might give it
>>higher priority - but do you need the IETF for that right now,
>>as long as you obey RFC 3697?
> 
> 
> FWIW, my personal take --
> 
> It might possibly make sense to set up a mailing list on IPv6 flow 
> label usage, try to solicit people to join it, propose and discuss 
> various proposals... and depending on how it goes, try to run a BOF at 
> the next meeting to gauge the real interest.
> 
> Even if there is not sufficient interest, I believe it's vital to 
> success to get those people interested of the flow label together.
> 
> At the first stage, the product might not be an IETF standards track 
> document, or even an IETF document -- e.g., an experimental RFC 
> through RFC-editor developed based on the mailing list discussion, but 
> that would be at least a basis for further work w/ flow label.
> 
> In other words, it's important to get those diffserv/qos geeks in the 
> same list/room with IPv6 specialists and those who'd like to use flow 
> label in new, innovative ways .. and see what happens.
> 
> IMHO, in any case, v6ops-like generic WGs are probably not a good 
> place to get sufficient amount of interest & expertise together.
> 



From owner-v6ops@ops.ietf.org  Thu Nov  4 14:38:06 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25812
	for <v6ops-archive@lists.ietf.org>; Thu, 4 Nov 2004 14:38:05 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CPnQB-000FH6-Hm
	for v6ops-data@psg.com; Thu, 04 Nov 2004 19:37:23 +0000
Received: from [161.114.64.103] (helo=zmamail03.zma.compaq.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CPnQ4-000FGa-JO
	for v6ops@ops.ietf.org; Thu, 04 Nov 2004 19:37:16 +0000
Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186])
	by zmamail03.zma.compaq.com (Postfix) with ESMTP id 31BF0C7
	for <v6ops@ops.ietf.org>; Thu,  4 Nov 2004 14:37:16 -0500 (EST)
Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211);
	 Thu, 4 Nov 2004 14:37:15 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: Comments: draft-suryanarayanan-v6ops-zeroconf-reqs-01.txt
Date: Thu, 4 Nov 2004 14:37:13 -0500
Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B07C4C5C5@tayexc13.americas.cpqcorp.net>
Thread-Topic: Comments: draft-suryanarayanan-v6ops-zeroconf-reqs-01.txt
Thread-Index: AcTAHDhtaE25OJi3Tz2ikyL2oaJ6vwCiA9zg
From: "Bound, Jim" <jim.bound@hp.com>
To: <v6ops@ops.ietf.org>
X-OriginalArrivalTime: 04 Nov 2004 19:37:15.0981 (UTC) FILETIME=[B08057D0:01C4C2A5]
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

Same comments as the previous on 3GPP zeronconf but this spec does
address IP4-in-IPv6 tunneling which is good all be it only basically and
needs more work.  But again has assumptions of the network working in
lieu of NATS ad Firewalls and I am not clear that is a valid assumption
for many cases. =20

http://www.v6ops.euro6ix.net/ietf/draft-suryanarayanan-v6ops-zeroconf-re
qs-01.txt

It seems to be that this zerconf spec, 3gpp zerconf spec, and assisted
tunneling spec have many common properties and could we reduce this to
just one spec?

Thanks
/jim




From owner-v6ops@ops.ietf.org  Thu Nov  4 14:40:59 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26055
	for <v6ops-archive@lists.ietf.org>; Thu, 4 Nov 2004 14:40:59 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CPnTW-000FfW-P7
	for v6ops-data@psg.com; Thu, 04 Nov 2004 19:40:50 +0000
Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CPnTV-000FfA-Iu
	for v6ops@ops.ietf.org; Thu, 04 Nov 2004 19:40:49 +0000
Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131])
	by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id iA4JemGn005686
	for <v6ops@ops.ietf.org>; Thu, 4 Nov 2004 19:40:48 GMT
Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162])
	by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id TAA29995
	for <v6ops@ops.ietf.org>; Thu, 4 Nov 2004 19:40:47 GMT
Received: (from tjc@localhost)
	by login.ecs.soton.ac.uk (8.11.6/8.11.6) id iA4JelQ04267
	for v6ops@ops.ietf.org; Thu, 4 Nov 2004 19:40:47 GMT
Date: Thu, 4 Nov 2004 19:40:47 +0000
From: Tim Chown <tjc@ecs.soton.ac.uk>
To: v6ops@ops.ietf.org
Subject: Re: A personal take on WG's priorities..
Message-ID: <20041104194047.GB1480@login.ecs.soton.ac.uk>
Mail-Followup-To: v6ops@ops.ietf.org
References: <BDAFC159.4DD4D%jordi.palet@consulintel.es> <Pine.LNX.4.61.0411042029200.20621@netcore.fi>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.61.0411042029200.20621@netcore.fi>
User-Agent: Mutt/1.4i
X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information
X-ECS-MailScanner: Found to be clean
X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

On Thu, Nov 04, 2004 at 09:07:33PM +0200, Pekka Savola wrote:
> 
> Putting all the work relating to protocols certainly seems to be a 
> relatively easily separable piece of the current charter.

Stepping up a mile or two, there is some appeal to having two WG threads,
be it one WG or two WGs:

WG1: "Operational issues with IPv6" that 
  a) analyses scenarios and identifies issues, documents requirements 
     from the issues
  b) produces informational documents on bcp in deployment
 
WG2: "IPv6 transition mechanisms" (ironically back to ngtrans :) that:
  a) takes requirements from WG1 and breaks out specific protocol proposals
  b) defines the protocols, may be more than one protocol per problem space,
     though ideally there is just one

> Campus transition, yes -- if Tim and others think it's worth 
> publishing.

For me, that I-D is a) a validator for testing ent-scenrios usefulness (which
I think it passed) and b) a place to document the transition tools we're
using on site, plus some random other issues that probably are best left
outside such an I-D :)   Some people seemed to like it though.
 
>  - finish enterprise analysis

So now we know why you and Jonne are the chairs :)

>  - draft-chown-v6ops-vlan-usage

This is kind of ready, but can wait for ent-analysis.  It's easy to point
people at a draft if they ask about it.   Most people are just doing it.
 
>  - security overview of IPv6

This is a biggie lurking low down on your list.

>  - draft-chown-v6ops-port-scanning-implications

I thought this would be part of "security overview of IPv6" but really it's
actually part of "BCP on enterprise IPv6 address planning".  After the
IETF there's a small (6NET) group working on an I-D in that area from
exerience gained to date.
 
>  - draft-chown-v6ops-renumber-thinkabout-00 (maybe)

That one is a scoping document for some 6NET-related work, also with Cisco,
and is helping us to define experiments to run to evaluate support for
renumbering in IPv6 networks.   It complements Fred's draft (RFC to be).
The audience of it is broad, not just an admin about to do a renumbering.

Tim



From owner-v6ops@ops.ietf.org  Thu Nov  4 15:12:09 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29322
	for <v6ops-archive@lists.ietf.org>; Thu, 4 Nov 2004 15:12:09 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CPnw4-000JaD-9p
	for v6ops-data@psg.com; Thu, 04 Nov 2004 20:10:20 +0000
Received: from [161.114.64.103] (helo=zmamail03.zma.compaq.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CPnvw-000JZG-VD
	for v6ops@ops.ietf.org; Thu, 04 Nov 2004 20:10:13 +0000
Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127])
	by zmamail03.zma.compaq.com (Postfix) with ESMTP id 96DFFA3DE
	for <v6ops@ops.ietf.org>; Thu,  4 Nov 2004 15:10:12 -0500 (EST)
Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211);
	 Thu, 4 Nov 2004 15:10:12 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Tunnel Discovery
Date: Thu, 4 Nov 2004 15:10:10 -0500
Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B07C4C5D2@tayexc13.americas.cpqcorp.net>
Thread-Topic: Tunnel Discovery
Thread-Index: AcTCnNmlhbjwBp5DTgirTmqHNAtpNQADU6pg
From: "Bound, Jim" <jim.bound@hp.com>
To: <Alain.Durand@Sun.COM>
Cc: <v6ops@ops.ietf.org>
X-OriginalArrivalTime: 04 Nov 2004 20:10:12.0425 (UTC) FILETIME=[4A8DC390:01C4C2AA]
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

I agree Alan with your mail below.  And yes add that one too "discovery"
below and I have read that too.  Yes it is critical and I just think we
can reduce the number of specs maybe?
Thanks
/jim=20

> -----Original Message-----
> From: Alain.Durand@Sun.COM [mailto:Alain.Durand@Sun.COM]=20
> Sent: Thursday, November 04, 2004 1:35 PM
> To: Bound, Jim
> Cc: v6ops@ops.ietf.org
> Subject: Re: Tunnel Discovery
>=20
> Bound, Jim wrote:
>=20
> >Appears to me we have a few specs doing tunnel endpoint discovery or=20
> >automation of tunnels.  At this point I think we need to see=20
> if we need=20
> >one document.  Two I reviewed are below:
> >
> >draft-palet-v6ops-solution-tun-auto-disc-01.txt
> >
> >The above has good uses cases but I am not clear DNS should=20
> be used in=20
> >the manner suggested operationally.
> > =20
> >
>=20
> There is also:
> http://www.ietf.org/internet-drafts/draft-yamamoto-naptr-servi
> ce-discovery-00.txt
>=20
> >draft-ietf-v6ops-assisted-tunneling-requirements-01.txt
> >
> >The above is approaching the problem correctly and a good=20
> piece of work.
> >And also a good vechicle to documet the various issues and=20
> >opportunities for work.
> > =20
> >
> This one is a requirement document, not a solution one..
>=20
> >Does the working group believe tunnel discovery is important to=20
> >automate or have means to set up policy or do we leave to=20
> the market,=20
> >given all other work we have to do?  I don't know right now?
> > =20
> >
> IMHO, this is/should be on the critical path of this wg.
>=20
>     - Alain.
>=20



From owner-v6ops@ops.ietf.org  Thu Nov  4 15:14:35 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29692
	for <v6ops-archive@lists.ietf.org>; Thu, 4 Nov 2004 15:14:34 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CPnzz-000Jsc-DJ
	for v6ops-data@psg.com; Thu, 04 Nov 2004 20:14:23 +0000
Received: from [161.114.64.105] (helo=zmamail05.zma.compaq.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CPnzy-000JsM-Au
	for v6ops@ops.ietf.org; Thu, 04 Nov 2004 20:14:22 +0000
Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127])
	by zmamail05.zma.compaq.com (Postfix) with ESMTP id F033BABD5;
	Thu,  4 Nov 2004 15:14:21 -0500 (EST)
Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211);
	 Thu, 4 Nov 2004 15:14:21 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Flow Label [Re: A personal take on WG's priorities..]
Date: Thu, 4 Nov 2004 15:14:19 -0500
Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B07C4C5D5@tayexc13.americas.cpqcorp.net>
Thread-Topic: Flow Label [Re: A personal take on WG's priorities..]
Thread-Index: AcTCnqQoF2MAlN15QfyhRH9FbqPLhgAC9oUw
From: "Bound, Jim" <jim.bound@hp.com>
To: "Sham Chakravorty" <schakra@mitre.org>, "Pekka Savola" <pekkas@netcore.fi>
Cc: <v6ops@ops.ietf.org>
X-OriginalArrivalTime: 04 Nov 2004 20:14:21.0734 (UTC) FILETIME=[DF274C60:01C4C2AA]
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

One of the good things about this wg is it is managed well and we are
doing good with prioritization so anything we do here even in a queue is
a good idea. =20

What we might want to do is spin off topics per pekka's mail on
categories kind of having mini groups within the WG.  I think the more
we focus to one pivotal leadership ergo jonne and pekka the better the
chance for cohesion and process completion and all of this is
integrated.

What Sham and I and others are proposing is an operational change first
to the view of the flow label then clearly we need to take our work for
traffic engineering to correct IETF venue.

Thanks
/jim=20

> -----Original Message-----
> From: owner-v6ops@ops.ietf.org=20
> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Sham Chakravorty
> Sent: Thursday, November 04, 2004 1:46 PM
> To: 'Pekka Savola'
> Cc: v6ops@ops.ietf.org
> Subject: RE: Flow Label [Re: A personal take on WG's priorities..]
>=20
> Pekka,=20
>=20
> We have plans similar to what you suggest.  But I sincerely=20
> believe that your WG is the place for Flow Label discussion. =20
> If resources don't allow such added work, then that's=20
> something that needs to be pursued.
>=20
> Sham
>=20
> -----Original Message-----
> From: owner-v6ops@ops.ietf.org=20
> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Pekka Savola
> Sent: Thursday, November 04, 2004 12:49 PM
> To: Brian E Carpenter
> Cc: Sham Chakravorty; v6ops@ops.ietf.org
> Subject: Re: Flow Label [Re: A personal take on WG's priorities..]
>=20
>=20
> On Thu, 4 Nov 2004, Brian E Carpenter wrote:
> > Sham, the flow label is low on my personal priority list.
> > The reason I was eager to get RFC 3697 done is to set boundary=20
> > conditions on its use, but developing the actual use cases=20
> seems to me=20
> > to be off the critical path for the IETF.
> >
> > Looking at your email address, I can see why you might give=20
> it higher=20
> > priority - but do you need the IETF for that right now, as=20
> long as you=20
> > obey RFC 3697?
>=20
> FWIW, my personal take --
>=20
> It might possibly make sense to set up a mailing list on IPv6=20
> flow label usage, try to solicit people to join it, propose=20
> and discuss various proposals... and depending on how it=20
> goes, try to run a BOF at the next meeting to gauge the real interest.
>=20
> Even if there is not sufficient interest, I believe it's=20
> vital to success to get those people interested of the flow=20
> label together.
>=20
> At the first stage, the product might not be an IETF=20
> standards track document, or even an IETF document -- e.g.,=20
> an experimental RFC through RFC-editor developed based on the=20
> mailing list discussion, but that would be at least a basis=20
> for further work w/ flow label.
>=20
> In other words, it's important to get those diffserv/qos=20
> geeks in the same list/room with IPv6 specialists and those=20
> who'd like to use flow label in new, innovative ways .. and=20
> see what happens.
>=20
> IMHO, in any case, v6ops-like generic WGs are probably not a=20
> good place to get sufficient amount of interest & expertise together.
>=20
> --=20
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>=20
>=20
>=20
>=20
>=20



From owner-v6ops@ops.ietf.org  Thu Nov  4 15:16:22 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29879
	for <v6ops-archive@lists.ietf.org>; Thu, 4 Nov 2004 15:16:22 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CPo1i-000K4r-TA
	for v6ops-data@psg.com; Thu, 04 Nov 2004 20:16:10 +0000
Received: from [161.114.64.104] (helo=zmamail04.zma.compaq.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CPo1h-000K4M-Tl
	for v6ops@ops.ietf.org; Thu, 04 Nov 2004 20:16:10 +0000
Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186])
	by zmamail04.zma.compaq.com (Postfix) with ESMTP id 9B5215361;
	Thu,  4 Nov 2004 15:16:09 -0500 (EST)
Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211);
	 Thu, 4 Nov 2004 15:16:09 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: WG last call on tunneling scenarios
Date: Thu, 4 Nov 2004 15:16:07 -0500
Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B07C4C5D7@tayexc13.americas.cpqcorp.net>
Thread-Topic: WG last call on tunneling scenarios
Thread-Index: AcTCo70zTMbH2C7qQa2mS0t0hOzMYgAB0FEA
From: "Bound, Jim" <jim.bound@hp.com>
To: "Pekka Savola" <pekkas@netcore.fi>, <v6ops@ops.ietf.org>
X-OriginalArrivalTime: 04 Nov 2004 20:16:09.0404 (UTC) FILETIME=[1F546FC0:01C4C2AB]
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

OK I messed up I thought the call was to make them WG items?  Not IETF
last WG call?  Did I miss a mail?  Sorry. I support them as WG items but
I think they need work before unloading on our IESG ADs.

Thanks
/jim=20

> -----Original Message-----
> From: owner-v6ops@ops.ietf.org=20
> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Pekka Savola
> Sent: Thursday, November 04, 2004 2:22 PM
> To: v6ops@ops.ietf.org
> Subject: Re: WG last call on tunneling scenarios
>=20
> For those who already deleted the email with the pointers,=20
> here they are again:
>=20
> http://www.ietf.org/internet-drafts/draft-nielsen-v6ops-3GPP-z
> eroconf-goals-00.txt
> http://www.v6ops.euro6ix.net/ietf/draft-suryanarayanan-v6ops-z
> eroconf-reqs-01.txt
> http://www.ietf.org/internet-drafts/draft-ietf-v6ops-assisted-
> tunneling-requirements-01.txt
>=20
>=20
> On Wed, 3 Nov 2004, Pekka Savola wrote:
> > On Sat, 30 Oct 2004, Pekka Savola wrote:
> >> Fair enough.  Please send the objections (if any) on document=20
> >> adoption by the end of Tuesday 2nd November at the latest.
> >>=20
> >> Comments/review on the drafts themselves are still welcome!
> >
> > (hat on)
> >
> > As there were no specific objections to adopting these documents,=20
> > there appears to be rough consensus on taking these as WG items.
> >
> > Let's continue the WG last call as called out earlier.
> >
> > *** We really need the reviews, and that means *YOU* too! :) ***
> >
> > (hat off)
> >
>=20
> --=20
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>=20
>=20



From owner-v6ops@ops.ietf.org  Thu Nov  4 15:17:10 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29967
	for <v6ops-archive@lists.ietf.org>; Thu, 4 Nov 2004 15:17:10 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CPo2W-000KAG-Fc
	for v6ops-data@psg.com; Thu, 04 Nov 2004 20:17:00 +0000
Received: from [161.114.64.103] (helo=zmamail03.zma.compaq.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CPo2V-000KA1-Dl
	for v6ops@ops.ietf.org; Thu, 04 Nov 2004 20:16:59 +0000
Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127])
	by zmamail03.zma.compaq.com (Postfix) with ESMTP id E9CAC6F
	for <v6ops@ops.ietf.org>; Thu,  4 Nov 2004 15:16:58 -0500 (EST)
Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211);
	 Thu, 4 Nov 2004 15:16:58 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Tunnel Discovery
Date: Thu, 4 Nov 2004 15:16:57 -0500
Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B07C4C5E1@tayexc13.americas.cpqcorp.net>
Thread-Topic: Tunnel Discovery
Thread-Index: AcTCnNmlhbjwBp5DTgirTmqHNAtpNQADU6pgAABBTDA=
From: "Bound, Jim" <jim.bound@hp.com>
To: "Bound, Jim" <jim.bound@hp.com>, <Alain.Durand@Sun.COM>
Cc: <v6ops@ops.ietf.org>
X-OriginalArrivalTime: 04 Nov 2004 20:16:58.0779 (UTC) FILETIME=[3CC276B0:01C4C2AB]
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

Sorry in public place and fingers are not working. I mean't "Alain".
Apologies to Alain.
/jim=20

> -----Original Message-----
> From: owner-v6ops@ops.ietf.org=20
> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Bound, Jim
> Sent: Thursday, November 04, 2004 3:10 PM
> To: Alain.Durand@Sun.COM
> Cc: v6ops@ops.ietf.org
> Subject: RE: Tunnel Discovery
>=20
> I agree Alan with your mail below.  And yes add that one too=20
> "discovery"
> below and I have read that too.  Yes it is critical and I=20
> just think we can reduce the number of specs maybe?
> Thanks
> /jim=20
>=20
> > -----Original Message-----
> > From: Alain.Durand@Sun.COM [mailto:Alain.Durand@Sun.COM]
> > Sent: Thursday, November 04, 2004 1:35 PM
> > To: Bound, Jim
> > Cc: v6ops@ops.ietf.org
> > Subject: Re: Tunnel Discovery
> >=20
> > Bound, Jim wrote:
> >=20
> > >Appears to me we have a few specs doing tunnel endpoint=20
> discovery or=20
> > >automation of tunnels.  At this point I think we need to see
> > if we need
> > >one document.  Two I reviewed are below:
> > >
> > >draft-palet-v6ops-solution-tun-auto-disc-01.txt
> > >
> > >The above has good uses cases but I am not clear DNS should
> > be used in
> > >the manner suggested operationally.
> > > =20
> > >
> >=20
> > There is also:
> > http://www.ietf.org/internet-drafts/draft-yamamoto-naptr-servi
> > ce-discovery-00.txt
> >=20
> > >draft-ietf-v6ops-assisted-tunneling-requirements-01.txt
> > >
> > >The above is approaching the problem correctly and a good
> > piece of work.
> > >And also a good vechicle to documet the various issues and=20
> > >opportunities for work.
> > > =20
> > >
> > This one is a requirement document, not a solution one..
> >=20
> > >Does the working group believe tunnel discovery is important to=20
> > >automate or have means to set up policy or do we leave to
> > the market,
> > >given all other work we have to do?  I don't know right now?
> > > =20
> > >
> > IMHO, this is/should be on the critical path of this wg.
> >=20
> >     - Alain.
> >=20
>=20
>=20



From owner-v6ops@ops.ietf.org  Thu Nov  4 15:24:38 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00896
	for <v6ops-archive@lists.ietf.org>; Thu, 4 Nov 2004 15:24:38 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CPo9U-000Kmz-5h
	for v6ops-data@psg.com; Thu, 04 Nov 2004 20:24:12 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CPo9Q-000Kmc-2Y
	for v6ops@ops.ietf.org; Thu, 04 Nov 2004 20:24:08 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id iA4KO2l23294;
	Thu, 4 Nov 2004 22:24:02 +0200
Date: Thu, 4 Nov 2004 22:24:02 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: "Bound, Jim" <jim.bound@hp.com>
cc: v6ops@ops.ietf.org
Subject: RE: WG last call on tunneling scenarios
In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B07C4C5D7@tayexc13.americas.cpqcorp.net>
Message-ID: <Pine.LNX.4.61.0411042221260.22885@netcore.fi>
References: <9C422444DE99BC46B3AD3C6EAFC9711B07C4C5D7@tayexc13.americas.cpqcorp.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

On Thu, 4 Nov 2004, Bound, Jim wrote:
> OK I messed up I thought the call was to make them WG items?  Not IETF
> last WG call?  Did I miss a mail?  Sorry. I support them as WG items but
> I think they need work before unloading on our IESG ADs.

I don't think we can unload them to the IESG just yet, but if you (ALL 
OF YOU) can, please provide as much and as concrete feedback as you 
can how to make them 'work better'.

We really need to get people to read these and comment on them. 
They'll be in a critical role when deciding which protocols to 
standardize, with which features, whether new protocols are needed, 
etc.

-- 
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 owner-v6ops@ops.ietf.org  Thu Nov  4 15:34:58 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01762
	for <v6ops-archive@lists.ietf.org>; Thu, 4 Nov 2004 15:34:58 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CPoJZ-000Llt-AN
	for v6ops-data@psg.com; Thu, 04 Nov 2004 20:34:37 +0000
Received: from [161.114.64.105] (helo=zmamail05.zma.compaq.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CPoJY-000LlX-CB
	for v6ops@ops.ietf.org; Thu, 04 Nov 2004 20:34:36 +0000
Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127])
	by zmamail05.zma.compaq.com (Postfix) with ESMTP id E66F41D67;
	Thu,  4 Nov 2004 15:34:35 -0500 (EST)
Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211);
	 Thu, 4 Nov 2004 15:34:35 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: WG last call on tunneling scenarios
Date: Thu, 4 Nov 2004 15:34:33 -0500
Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B07C4C5EC@tayexc13.americas.cpqcorp.net>
Thread-Topic: WG last call on tunneling scenarios
Thread-Index: AcTCrDyPZnPcllgJR+ONooA9scr3kQAAVcGg
From: "Bound, Jim" <jim.bound@hp.com>
To: "Pekka Savola" <pekkas@netcore.fi>
Cc: <v6ops@ops.ietf.org>
X-OriginalArrivalTime: 04 Nov 2004 20:34:35.0759 (UTC) FILETIME=[B2C4CFF0:01C4C2AD]
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

Ok will do.  But working on edit of ent analysis...as priortiy.

What about consolidatinng tunnel specs or do you think these should all
go forward individually?

Thanks
/jim=20

> -----Original Message-----
> From: Pekka Savola [mailto:pekkas@netcore.fi]=20
> Sent: Thursday, November 04, 2004 3:24 PM
> To: Bound, Jim
> Cc: v6ops@ops.ietf.org
> Subject: RE: WG last call on tunneling scenarios
>=20
> On Thu, 4 Nov 2004, Bound, Jim wrote:
> > OK I messed up I thought the call was to make them WG=20
> items?  Not IETF=20
> > last WG call?  Did I miss a mail?  Sorry. I support them as=20
> WG items=20
> > but I think they need work before unloading on our IESG ADs.
>=20
> I don't think we can unload them to the IESG just yet, but if=20
> you (ALL OF YOU) can, please provide as much and as concrete=20
> feedback as you can how to make them 'work better'.
>=20
> We really need to get people to read these and comment on them.=20
> They'll be in a critical role when deciding which protocols=20
> to standardize, with which features, whether new protocols=20
> are needed, etc.
>=20
> --=20
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>=20



From owner-v6ops@ops.ietf.org  Thu Nov  4 15:36:45 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01909
	for <v6ops-archive@lists.ietf.org>; Thu, 4 Nov 2004 15:36:45 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CPoLU-000M6R-UZ
	for v6ops-data@psg.com; Thu, 04 Nov 2004 20:36:36 +0000
Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CPoLU-000M64-1A
	for v6ops@ops.ietf.org; Thu, 04 Nov 2004 20:36:36 +0000
Received: from esunmail ([129.147.156.34])
	by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id iA4KaZui004339
	for <v6ops@ops.ietf.org>; Thu, 4 Nov 2004 13:36:35 -0700 (MST)
Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM
 (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTP id <0I6O00GWK98ZLM@edgemail1.Central.Sun.COM> for
 v6ops@ops.ietf.org; Thu, 04 Nov 2004 13:36:35 -0700 (MST)
Received: from [192.168.1.102] ([66.93.39.75])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I6O0036B98Y24@mail.sun.net> for v6ops@ops.ietf.org; Thu,
 04 Nov 2004 13:36:35 -0700 (MST)
Date: Thu, 04 Nov 2004 12:38:13 -0800
From: Alain Durand <Alain.Durand@Sun.COM>
Subject: Re: Tunnel Discovery
In-reply-to: 
 <9C422444DE99BC46B3AD3C6EAFC9711B07C4C5D2@tayexc13.americas.cpqcorp.net>
To: "Bound, Jim" <jim.bound@hp.com>
Cc: v6ops@ops.ietf.org
Message-id: <418A9335.30406@sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20040906
References: 
 <9C422444DE99BC46B3AD3C6EAFC9711B07C4C5D2@tayexc13.americas.cpqcorp.net>
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7BIT

Bound, Jim wrote:

>I agree Alan with your mail below.  And yes add that one too "discovery"
>below and I have read that too.  Yes it is critical and I just think we can
>reduce the number of specs maybe?
>  
>
I sure expect so.

    - Alain.




From owner-v6ops@ops.ietf.org  Thu Nov  4 15:40:12 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02259
	for <v6ops-archive@lists.ietf.org>; Thu, 4 Nov 2004 15:40:12 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CPoOc-000Mi3-LL
	for v6ops-data@psg.com; Thu, 04 Nov 2004 20:39:50 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CPoOb-000MhM-Dq
	for v6ops@ops.ietf.org; Thu, 04 Nov 2004 20:39:49 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id iA4Kdgl23632;
	Thu, 4 Nov 2004 22:39:42 +0200
Date: Thu, 4 Nov 2004 22:39:42 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: "Bound, Jim" <jim.bound@hp.com>
cc: v6ops@ops.ietf.org
Subject: Re: Comments: draft-suryanarayanan-v6ops-zeroconf-reqs-01.txt
In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B07C4C5C5@tayexc13.americas.cpqcorp.net>
Message-ID: <Pine.LNX.4.61.0411042224170.22885@netcore.fi>
References: <9C422444DE99BC46B3AD3C6EAFC9711B07C4C5C5@tayexc13.americas.cpqcorp.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

Hi,

On Thu, 4 Nov 2004, Bound, Jim wrote:
> http://www.v6ops.euro6ix.net/ietf/draft-suryanarayanan-v6ops-zeroconf-re
> qs-01.txt
>
> It seems to be that this zerconf spec, 3gpp zerconf spec, and assisted
> tunneling spec have many common properties and could we reduce this to
> just one spec?

Yes, they certainly share a number of common properties.

However, the problem spaces they're covering seem to be slightly 
different.

In particular, the assisted tunneling assumes explicit user 
registration, which typically maps to providing the service to 
pre-agreed (registered) third parties or as a VPN-like service 
(without encryption).  Registered mode can of course also be used in a 
scenario where registration is not really necessary. If you will, one 
could imagine non-anonymous-mode TSP as an instance of this model.

Now, the explicit goal of both zero-conf documents is to avoid 
registration, and to provide just a simple, very easy way to obtain 
connectivity, without the bells and whistles.  One could consider 
ISATAP run inside an enterprise an example of this kind of solution, 
or a simplified, anonymous-mode, TSP-like solution.

Hence, there is IMHO some value in keeping these separate even though 
there is overlap.  On the other hand, I personally think that the 
documents do not currently describe sufficiently clearly what I wrote 
above, so a reader unfamiliar with the work is unlikely to see much 
difference there at least at first.

That said, if folks think more consolidation is good, to eliminate 
overlap and make it more concise, yes, that's a possibility -- please 
speak up.  This comes with the expense of blurring the (special, and 
conflicting) requirements of different scenarios, though.  Not an easy 
tradeoff.

(We actually tried to start with this project as one spec -- 
draft-ietf-v6ops-assisted-tunneling-requirements-00 intended to cover 
all the cases, but 3GPP folks wanted to separately clearly describe 
their own requirements, and then generalized case of 3GPP was also put 
in a separate document.  So, I guess this argues that there was 
attempt at doing just one document, and it didn't quite work out due 
to differences in requirements esp. from 3GPP..)

-- 
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 owner-v6ops@ops.ietf.org  Thu Nov  4 18:20:57 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22002
	for <v6ops-archive@lists.ietf.org>; Thu, 4 Nov 2004 18:20:56 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CPqr4-000COU-1E
	for v6ops-data@psg.com; Thu, 04 Nov 2004 23:17:22 +0000
Received: from [213.172.48.142] (helo=consulintel.es)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CPqr2-000CNg-HK
	for v6ops@ops.ietf.org; Thu, 04 Nov 2004 23:17:21 +0000
Received: from [10.10.10.102] ([217.126.187.160])
	by consulintel.es (consulintel.es [127.0.0.1])
	(MDaemon.PRO.v7.2.0.R)
	with ESMTP id md50000558605.msg
	for <v6ops@ops.ietf.org>; Fri, 05 Nov 2004 00:22:47 +0100
User-Agent: Microsoft-Entourage/10.1.4.030702.0
Date: Fri, 05 Nov 2004 00:17:08 +0100
Subject: Re: A personal take on WG's priorities..
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: <v6ops@ops.ietf.org>
Message-ID: <BDB07704.4DFB1%jordi.palet@consulintel.es>
In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B07C4C59D@tayexc13.americas.cpqcorp.net>
Mime-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
X-Spam-Processed: consulintel.es, Fri, 05 Nov 2004 00:22:47 +0100
	(not processed: message from valid local sender)
X-MDRemoteIP: 217.126.187.160
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ops.ietf.org
Reply-To: jordi.palet@consulintel.es
X-MDAV-Processed: consulintel.es, Fri, 05 Nov 2004 00:22:49 +0100
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

Jim,

My view is that we should only work in new transition mechanism if there is
something _really_ not covered already, but we also should work on those "de
facto" mechanism to get standardized if it make sense.

Regards,
Jordi

> De: "Bound, Jim" <jim.bound@hp.com>
> Responder a: owner-v6ops@ops.ietf.org
> Fecha: Thu, 4 Nov 2004 13:10:57 -0500
> Para: "Brian E Carpenter" <brc@zurich.ibm.com>, <jordi.palet@consulintel.es>
> CC: <v6ops@ops.ietf.org>
> Asunto: RE: A personal take on WG's priorities..
>=20
> But I don't agree we should not work on new emerging transition mechanisms
> that in fact are being deployed as we talk here.
> /jim=20
>=20
>> -----Original Message-----
>> From: owner-v6ops@ops.ietf.org
>> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Brian E Carpenter
>> Sent: Thursday, November 04, 2004 11:21 AM
>> To: jordi.palet@consulintel.es
>> Cc: v6ops@ops.ietf.org
>> Subject: Re: A personal take on WG's priorities..
>>=20
>> Jordi,
>>=20
>> It's Management 101. I don't think any WG with so many
>> diverse topics has a chance of making good progress. We need
>> to divide and conquer, IMHO.
>>=20
>>     Brian
>>=20
>> JORDI PALET MARTINEZ wrote:
>>> Hi Brian,
>>>=20
>>> May be I'm wrong, but if the objective to outsource some of
>> the work=20
>>> is to "evacuate" it faster, I think is not the right way.
>>>=20
>>> I mean, if they are within the charter, they are
>> operational issues,
>>> pushing it outside, will mean some of the people that is
>> doing effort=20
>>> here, will divide his time following up to WGs (at least),
>> attending 2 meetings, etc.
>>> At the end, some times this can be rather more time consuming that
>>> proceeding here. I've this experience in projects, when you
>> divide the=20
>>> work in several WGs and then becomes fragmented, and the
>> people, who=20
>>> is limited in number and resources, availability, etc.,
>> tend to keep=20
>>> only with part of the work, very concentrated and missing
>> the overall picture.
>>>=20
>>> Consequently, I will agree with this only in case we have extra
>>> effort, which is not the case, but in general in IETF on
>> the contrary.=20
>>> Less people less effort with the time ..., unfortunately.
>>>=20
>>> I will agree that if we have something that is clearly
>> specific to an=20
>>> existing WG, then it should be forwarded there. Similarly,
>> if there is=20
>>> some work that requires a very focused effort, then we
>> should try to=20
>>> create a new WG, probably.
>>>=20
>>> Regards,
>>> Jordi
>>>=20
>>>=20
>>>=20
>>>> De: Brian E Carpenter <brc@zurich.ibm.com>
>>>> Organizaci=F3n: IBM
>>>> Responder a: owner-v6ops@ops.ietf.org
>>>> Fecha: Thu, 04 Nov 2004 09:09:44 +0100
>>>> Para: Pekka Savola <pekkas@netcore.fi>
>>>> CC: v6ops@ops.ietf.org
>>>> Asunto: Re: A personal take on WG's priorities..
>>>>=20
>>>> Pekka,
>>>>=20
>>>> Loosely speaking, this list seems OK to me personally.
>>>>=20
>>>> Quite obviously, it would be outrageous to attempt all this
>> in one WG.=20
>>>> IMHO, we need to either out-source work to other WGs or
>> create several=20
>>>> new WGs with focussed charters.
>>>> Especially, we need to separate "getting known stuff fully
>>>> operational" from "doing new stuff."
>>>>=20
>>>>  Brian
>>>>=20
>>>> Pekka Savola wrote:
>>>>=20
>>>>> Hi,
>>>>>=20
>>>>> Based on the discussion on what the WG should be doing, I
>> cooked up=20
>>>>> my
>>>>> **personal** list of what I consider to be priorities, in
>> some rough=20
>>>>> categories.  As you see, there's a *LOT* that falls under the WG
>>>>> charter, and there is no way we could work on even 1/3 or 1/4 of
>>>>> these at the same time.  So, there must be some priorization.
>>>>>=20
>>>>> I welcome comments especially if you think I've badly
>> misprioritized=20
>>>>> document/work that relates to the v6ops charter.
>>>>>=20
>>>>> =3D=3D=3D=3D=3D=3D
>>>>>=20
>>>>> The most important work
>>>>> - finish enterprise analysis
>>>>> - finish requirement(s) for tunneling
>>>>>    * to be able to decide whether existing solution(s)
>> are sufficient
>>>>>      and if not, get started on specifying new ones
>>>>> - get started on mechanisms (somewhere else?) if needed/necessary
>>>>>=20
>>>>> Pretty darn important work
>>>>> - the last spin at 3GPP analysis doc, updated IMS scenario
>>>>> - better document the ISP's broadband transition scenarios
>>>>>    * draft-asadullah-v6ops-bb-deployment-scenarios-01
>>>>> - finish draft-ietf-v6ops-mech-v2
>>>>>    * waiting for feedback from the IESG telechat..
>>>>> - adopt and finish draft-tschofenig-v6ops-secure-tunnels-02.txt
>>>>>    * IESG requirement for draft-ietf-v6ops-mech-v2
>>>>> - figure what to do about the NAT-PT deprecation/analysis
>>>>>   *  draft-aoun-v6ops-natpt-deprecate
>>>>> - (techno-political) document for v4 NAT users
>>>>>   * draft-vandevelde-v6ops-nap
>>>>> - IPv6-on-by-default work, fixes need to be integrated in
>> the IETF work
>>>>>   * draft-ietf-v6ops-onlinkassumption
>>>>>   * draft-ietf-v6ops-v6onbydefault
>>>>>   * etc.
>>>>>=20
>>>>> Important work
>>>>> - draft-ietf-v6ops-renumbering-procedure
>>>>>   * needs revision to address IESG comments
>>>>> - draft-palet-v6ops-tun-auto-disc
>>>>> - draft-chown-v6ops-vlan-usage
>>>>> - figuring out how to deal with Mobile IP transition issues
>>>>> - security overview of IPv6
>>>>>    * draft-savola-v6ops-security-overview
>>>>>=20
>>>>> Useful work
>>>>> - revising 6to4 spec to be clearer, etc.
>>>>> - draft-palet-v6ops-solution-tun-auto-disc
>>>>> - draft-chown-v6ops-renumber-thinkabout-00
>>>>> - draft-chown-v6ops-port-scanning-implications
>>>>>=20
>>>>> Difficult to say whether it has gained sufficient
>> momentum, and/or
>>>>> whether this is the right place to do this
>>>>> - draft-palet-v6ops-auto-trans
>>>>> - draft-palet-v6ops-ipv6security
>>>>> - draft-vives-v6ops-ipv6-security-ps
>>>>> - draft-kondo-quarantine-overview-01.txt
>>>>>=20
>>>>> Not sure whether it should be published as RFC, or is sufficiently
>>>>> relevant
>>>>> - draft-chown-v6ops-campus-transition
>>>>> - draft-morelli-v6ops-ipv6-ix
>>>>>=20
>>>>=20
>>>>=20
>>>=20
>>>=20
>>>=20
>>> **********************************
>>> Madrid 2003 Global IPv6 Summit
>>> Presentations and videos on line at:
>>> http://www.ipv6-es.com
>>>=20
>>> 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.
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>=20
>>=20
>=20
>=20



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






From owner-v6ops@ops.ietf.org  Thu Nov  4 18:32:20 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23006
	for <v6ops-archive@lists.ietf.org>; Thu, 4 Nov 2004 18:32:19 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CPr40-000DTH-OA
	for v6ops-data@psg.com; Thu, 04 Nov 2004 23:30:44 +0000
Received: from [213.172.48.142] (helo=consulintel.es)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CPr3z-000DT3-Mp
	for v6ops@ops.ietf.org; Thu, 04 Nov 2004 23:30:43 +0000
Received: from [10.10.10.102] ([217.126.187.160])
	by consulintel.es (consulintel.es [127.0.0.1])
	(MDaemon.PRO.v7.2.0.R)
	with ESMTP id md50000558619.msg
	for <v6ops@ops.ietf.org>; Fri, 05 Nov 2004 00:36:12 +0100
User-Agent: Microsoft-Entourage/10.1.4.030702.0
Date: Fri, 05 Nov 2004 00:30:36 +0100
Subject: Re: Comments: draft-nielsen-v6ops-3GPP-zeroconf-goals-00.txt
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: <v6ops@ops.ietf.org>
Message-ID: <BDB07A2C.4DFEE%jordi.palet@consulintel.es>
In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B07C4C5C0@tayexc13.americas.cpqcorp.net>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Spam-Processed: consulintel.es, Fri, 05 Nov 2004 00:36:12 +0100
	(not processed: message from valid local sender)
X-MDRemoteIP: 217.126.187.160
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ops.ietf.org
Reply-To: jordi.palet@consulintel.es
X-MDAV-Processed: consulintel.es, Fri, 05 Nov 2004 00:36:13 +0100
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Jim,

I'm not sure to catch your point here, but the idea is to cover only the
situation when this tunneling is done within the 3GPP provider itself.

In that case, even if there are private addresses (and even NAT) proto-41 is
forwarded, so is possible to tunnel 6in4 w/o any trouble.

Regards,
Jordi


> De: "Bound, Jim" <jim.bound@hp.com>
> Responder a: owner-v6ops@ops.ietf.org
> Fecha: Thu, 4 Nov 2004 14:23:55 -0500
> Para: <v6ops@ops.ietf.org>
> Asunto: Comments: draft-nielsen-v6ops-3GPP-zeroconf-goals-00.txt
> 
> The spec once it speaks about tunneling is all over the place saying it
> can support private addresses, NATs etc.
> 
> http://www.ietf.org/internet-drafts/draft-nielsen-v6ops-3GPP-zeroconf-go
> als-00.txt
> 
> I think some of this is just impossible for mobility.  A real case in
> S.E. Asia right now looking at 3G IPv6 deployment has the following
> problem.  Mobile (seamless) nodes will use native IPv6 and IPv4 to get
> to legacy apps that have not been ported to IPv6.  In this case the
> problem is that public IPv4 addresses are needed.  But we know all that
> and we must address that case.  The other case is that to get to the IMS
> networks first you havce to tunnel the packet through IPv4 network to
> IMS IPv6 network.  This is not going to work with NAT when the user is
> roaming.  So I don't see why the spec does not say this.
> 
> Hence, my first input to this spec (and I do believe it should be WG
> item) is that we will need to discuss deployment profiles for mobility
> and more of enterprise nature than 3GPP nature.
> 
> Thanks
> /jim
> 
> 
> 



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






From owner-v6ops@ops.ietf.org  Thu Nov  4 18:35:43 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23353
	for <v6ops-archive@lists.ietf.org>; Thu, 4 Nov 2004 18:35:42 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CPr7U-000DoZ-6z
	for v6ops-data@psg.com; Thu, 04 Nov 2004 23:34:20 +0000
Received: from [213.172.48.142] (helo=consulintel.es)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CPr7T-000DoF-5e
	for v6ops@ops.ietf.org; Thu, 04 Nov 2004 23:34:19 +0000
Received: from [10.10.10.102] ([217.126.187.160])
	by consulintel.es (consulintel.es [127.0.0.1])
	(MDaemon.PRO.v7.2.0.R)
	with ESMTP id md50000558625.msg
	for <v6ops@ops.ietf.org>; Fri, 05 Nov 2004 00:39:47 +0100
User-Agent: Microsoft-Entourage/10.1.4.030702.0
Date: Fri, 05 Nov 2004 00:34:04 +0100
Subject: Re: Comments: draft-suryanarayanan-v6ops-zeroconf-reqs-01.txt
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: <v6ops@ops.ietf.org>
Message-ID: <BDB07AFC.4DFF5%jordi.palet@consulintel.es>
In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B07C4C5C5@tayexc13.americas.cpqcorp.net>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Spam-Processed: consulintel.es, Fri, 05 Nov 2004 00:39:47 +0100
	(not processed: message from valid local sender)
X-MDRemoteIP: 217.126.187.160
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ops.ietf.org
Reply-To: jordi.palet@consulintel.es
X-MDAV-Processed: consulintel.es, Fri, 05 Nov 2004 00:39:48 +0100
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Jim,

I totally agree here.

As one of the co-authors, I precisely asked to include other tunneling
options (namely 4in6 and 6in6) as a must.

In a message that I sent to the WG a few days ago, I explicitly asked the WG
opinion on that ...

Regarding to having a single document, the idea was initially like that, but
then we come out to the conclusion that is easier, because different small
particularities, to work in separate documents, and may be join some of them
at the end, but I'm now not absolutely clear about that being so easy.

Instead, if we can find a single solution for all the 3 requirement
documents ... then it will be easier at that point.

Regards,
Jordi


> De: "Bound, Jim" <jim.bound@hp.com>
> Responder a: owner-v6ops@ops.ietf.org
> Fecha: Thu, 4 Nov 2004 14:37:13 -0500
> Para: <v6ops@ops.ietf.org>
> Asunto: Comments: draft-suryanarayanan-v6ops-zeroconf-reqs-01.txt
> 
> Same comments as the previous on 3GPP zeronconf but this spec does
> address IP4-in-IPv6 tunneling which is good all be it only basically and
> needs more work.  But again has assumptions of the network working in
> lieu of NATS ad Firewalls and I am not clear that is a valid assumption
> for many cases.  
> 
> http://www.v6ops.euro6ix.net/ietf/draft-suryanarayanan-v6ops-zeroconf-re
> qs-01.txt
> 
> It seems to be that this zerconf spec, 3gpp zerconf spec, and assisted
> tunneling spec have many common properties and could we reduce this to
> just one spec?
> 
> Thanks
> /jim
> 
> 
> 



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






From owner-v6ops@ops.ietf.org  Thu Nov  4 18:40:56 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23629
	for <v6ops-archive@lists.ietf.org>; Thu, 4 Nov 2004 18:40:56 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CPrDM-000EVj-PS
	for v6ops-data@psg.com; Thu, 04 Nov 2004 23:40:24 +0000
Received: from [213.172.48.142] (helo=consulintel.es)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CPrDL-000EVN-NH
	for v6ops@ops.ietf.org; Thu, 04 Nov 2004 23:40:23 +0000
Received: from [10.10.10.102] ([217.126.187.160])
	by consulintel.es (consulintel.es [127.0.0.1])
	(MDaemon.PRO.v7.2.0.R)
	with ESMTP id md50000558628.msg
	for <v6ops@ops.ietf.org>; Fri, 05 Nov 2004 00:45:48 +0100
User-Agent: Microsoft-Entourage/10.1.4.030702.0
Date: Fri, 05 Nov 2004 00:40:08 +0100
Subject: Re: A personal take on WG's priorities..
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: <v6ops@ops.ietf.org>
Message-ID: <BDB07C68.4E009%jordi.palet@consulintel.es>
In-Reply-To: <Pine.LNX.4.61.0411042029200.20621@netcore.fi>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Spam-Processed: consulintel.es, Fri, 05 Nov 2004 00:45:48 +0100
	(not processed: message from valid local sender)
X-MDRemoteIP: 217.126.187.160
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ops.ietf.org
Reply-To: jordi.palet@consulintel.es
X-MDAV-Processed: consulintel.es, Fri, 05 Nov 2004 00:45:53 +0100
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Pekka,

Reply to only a minor part of your message.

This sound really weird. If you believe this is done, or almost, it make
sense to get this as WG item and make sure that the WG take a look (last
call process that we used to push the WG attention with other documents) ?

What is not sensible to me is to say, "will be needed, is almost done, but
...". I don't understand the but ! Is ridiculous to have a work done waiting
for ... may be another WG ? This will take then more time from the WG and
the IETF in general that closing it now !

Can we heard the rest of the WG opinion on this ?

Regards,
Jordi

>> Also, I think this
>>> - draft-palet-v6ops-tun-auto-disc
>> belongs to what I called Group 1, and is ready to be closed. Otherwise will
>> be good the received inputs, objections or whatever !
> 
> I don't disagree that this is rather close to being closed, but the
> question is of its urgency -- I think it'll be needed only when we
> start figuring out which kind of protocols we specify, or how we
> modify them.  (Granted, it would be useful if there was already
> consensus on that then.)
> 



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






From owner-v6ops@ops.ietf.org  Thu Nov  4 22:23:52 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11877
	for <v6ops-archive@lists.ietf.org>; Thu, 4 Nov 2004 22:23:52 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CPueA-000DWh-UG
	for v6ops-data@psg.com; Fri, 05 Nov 2004 03:20:18 +0000
Received: from [159.226.39.7] (helo=ict.ac.cn)
	by psg.com with smtp (Exim 4.41 (FreeBSD))
	id 1CPue9-000DWP-N6
	for v6ops@ops.ietf.org; Fri, 05 Nov 2004 03:20:18 +0000
Received: (qmail 31769 invoked by uid 507); 5 Nov 2004 02:52:36 -0000
Received: from unknown (HELO ThinkPadX31) (liumin@159.226.39.104)
  by ict.ac.cn with SMTP; 5 Nov 2004 02:52:36 -0000
From: "Liu Min" <liumin@ict.ac.cn>
To: "'Sham Chakravorty'" <schakra@mitre.org>, <v6ops@ops.ietf.org>
Subject: RE: A personal take on WG's priorities..
Date: Fri, 5 Nov 2004 11:20:06 +0800
Message-ID: <000701c4c2e6$5fa65760$4b74a8c0@ThinkPadX31>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
Importance: Normal
In-Reply-To: <012c01c4c271$9d19c020$11181d80@MITRE.ORG>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

I also want to know if we want to make some suggestion or present some
proposal for IPv6 Flow Label, where should we do it. When we introduce =
IPv6,
the Flow Label and Traffic Class, and its support for QoS are always one
topic. However, you can not present a QoS mechanism or a network =
measurement
tool using Flow Label and Traffic Class, because they are still =
experimental
and subject to change.=20

=20
Best Wishes,
=20

Liu Min
=20
Institute of Computing Technology
Chinese Academy of Sciences
Tel: (86-10) 6256 5533-9240=20
E-mail: liumin@ict.ac.cn


> -----Original Message-----
> From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On =
Behalf
> Of Sham Chakravorty
> Sent: Thursday, November 04, 2004 9:24 PM
> To: v6ops@ops.ietf.org
> Subject: RE: A personal take on WG's priorities..
>=20
> In this regard, would it make sense to add IPv6 Flow Label usage in a
> "sub-WG" area such as Enterprise or IPv6 Traffic Modeling?  One would
think
> this is one of the  key IPv6 operations areas.  It seems to me we are
> focused only in a few, narrowly focused areas of IPv6 operations (as
> reflected in the charter).
>=20
> Sham Chakravorty
>=20
> -----Original Message-----
> From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On =
Behalf
> Of EricLKlein
> Sent: Thursday, November 04, 2004 3:30 AM
> To: v6ops@ops.ietf.org
> Subject: Re: A personal take on WG's priorities..
>=20
>=20
> From: "Brian
> > Quite obviously, it would be outrageous to attempt all this
> > in one WG. IMHO, we need to either out-source work to other
> > WGs or create several new WGs with focussed charters.
> > Especially, we need to separate "getting known stuff
> > fully operational" from "doing new stuff."
>=20
> Is it possible to try to set up "sub-WG" areas and recruit more
specialized
> people into these areas?
>=20
> I am thinking (of the top of my head) of three subgroups:
> - Enterprise - would include migration issues, etc.
> - ISPs - would handle tunnels, interconnections, etc
> - IPv6 Security - would handle NAT-PT, depreciating NAT in IPv6, etc.
>=20
> Just a thought.
> Eric
>=20
>=20
>=20
>=20
>=20
>=20






From owner-v6ops@ops.ietf.org  Fri Nov  5 01:14:17 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22008
	for <v6ops-archive@lists.ietf.org>; Fri, 5 Nov 2004 01:14:17 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CPxJT-0008Zm-5Y
	for v6ops-data@psg.com; Fri, 05 Nov 2004 06:11:07 +0000
Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CPxJS-0008ZZ-6A
	for v6ops@ops.ietf.org; Fri, 05 Nov 2004 06:11:06 +0000
Received: from esunmail ([129.147.156.34])
	by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id iA56B5ui017918
	for <v6ops@ops.ietf.org>; Thu, 4 Nov 2004 23:11:05 -0700 (MST)
Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM
 (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTP id <0I6O0000SZUGUD@edgemail1.Central.Sun.COM> for
 v6ops@ops.ietf.org; Thu, 04 Nov 2004 23:11:05 -0700 (MST)
Received: from [192.168.1.2] ([66.93.39.75])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I6O004Q5ZUE1S@mail.sun.net> for v6ops@ops.ietf.org; Thu,
 04 Nov 2004 23:11:04 -0700 (MST)
Date: Thu, 04 Nov 2004 22:11:01 -0800
From: Alain Durand <Alain.Durand@Sun.COM>
Subject: Re: Comments: draft-nielsen-v6ops-3GPP-zeroconf-goals-00.txt
In-reply-to: 
 <9C422444DE99BC46B3AD3C6EAFC9711B07C4C5C0@tayexc13.americas.cpqcorp.net>
To: "Bound, Jim" <jim.bound@hp.com>
Cc: v6ops@ops.ietf.org
Message-id: <77F9E572-2EF1-11D9-AC14-00039376A6AA@sun.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.619)
Content-type: multipart/alternative;
 boundary="Boundary_(ID_0e4eRJu7SqhyjQSJn845lg)"
References: 
 <9C422444DE99BC46B3AD3C6EAFC9711B07C4C5C0@tayexc13.americas.cpqcorp.net>
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk


--Boundary_(ID_0e4eRJu7SqhyjQSJn845lg)
Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Content-Transfer-Encoding: 7BIT


On Nov 4, 2004, at 11:23 AM, Bound, Jim wrote:

> The spec once it speaks about tunneling is all over the place saying it
> can support private addresses, NATs etc.
>
> http://www.ietf.org/internet-drafts/draft-nielsen-v6ops-3GPP-zeroconf- 
> go
> als-00.txt
>
> I think some of this is just impossible for mobility.  A real case in
> S.E. Asia right now looking at 3G IPv6 deployment has the following
> problem.  Mobile (seamless) nodes will use native IPv6 and IPv4 to get
> to legacy apps that have not been ported to IPv6.  In this case the
> problem is that public IPv4 addresses are needed.  But we know all that
> and we must address that case.  The other case is that to get to the  
> IMS
> networks first you havce to tunnel the packet through IPv4 network to
> IMS IPv6 network.  This is not going to work with NAT when the user is
> roaming.  So I don't see why the spec does not say this.

According to draft-nielsen-v6ops-3GPP-zeroconf-goals-00.txt (section  
4.1. Applicability Assumptions)
the PDP context has to be terminated at the "home" network GGSN, even  
if the user
is actually roaming in a foreign network. Thus, even if private IPv4  
addresses are used,
there would be no NAT between the UE an the tunnel server.

I think the confusion is coming from the introduction text:
 >   Configuration tunneling will in the 3GPP environment be deployed for
 >   the following purposes:
 >      - To provide temporary provisioning of basic IPv6 services, which
 >        users may deploy for the simplest IPv6 services only.
 >      - To allow an Operator, possibly a native IPv6 enabled Operator,
 >        to provide basic IPv6 services to users roaming into foreign
 >        networks which supports IPv4 bearer connectivity only.

In the second case, the fact that the foreign network is offering IPv4  
only or
IPv6 only or a mix of the two is irrelevant as the PDP context will be  
terminated in the home network.
The introduction text should clarify this point.

I have other comments that I will sent in a different thread.

	- Alain.




--Boundary_(ID_0e4eRJu7SqhyjQSJn845lg)
Content-type: text/enriched; charset=US-ASCII
Content-Transfer-Encoding: 7BIT

<fontfamily><param>Arial</param>

On Nov 4, 2004, at 11:23 AM, Bound, Jim wrote:


<excerpt>The spec once it speaks about tunneling is all over the place
saying it

can support private addresses, NATs etc.


http://www.ietf.org/internet-drafts/draft-nielsen-v6ops-3GPP-zeroconf-go

als-00.txt


I think some of this is just impossible for mobility.  A real case in

S.E. Asia right now looking at 3G IPv6 deployment has the following

problem.  Mobile (seamless) nodes will use native IPv6 and IPv4 to get

to legacy apps that have not been ported to IPv6.  In this case the

problem is that public IPv4 addresses are needed.  But we know all that

and we must address that case.  The other case is that to get to the
IMS

networks first you havce to tunnel the packet through IPv4 network to

IMS IPv6 network.  This is not going to work with NAT when the user is

roaming.  So I don't see why the spec does not say this.

</excerpt>

According to draft-nielsen-v6ops-3GPP-zeroconf-goals-00.txt (section
4.1. Applicability Assumptions)

the PDP context has to be terminated at the "home" network GGSN, even
if the user

is actually roaming in a foreign network. Thus, even if private IPv4
addresses are used,

there would be no NAT between the UE an the tunnel server.


I think the confusion is coming from the introduction text:

>   Configuration tunneling will in the 3GPP environment be deployed
for

>   the following purposes:

>      - To provide temporary provisioning of basic IPv6 services,
which

>        users may deploy for the simplest IPv6 services only.

>      - To allow an Operator, possibly a native IPv6 enabled Operator,

>        to provide basic IPv6 services to users roaming into foreign

>        networks which supports IPv4 bearer connectivity only.


In the second case, the fact that the foreign network is offering IPv4
only or

IPv6 only or a mix of the two is irrelevant as the PDP context will be
terminated in the home network.

The introduction text should clarify this point.


I have other comments that I will sent in a different thread.


	- Alain.</fontfamily><bold>

</bold>




--Boundary_(ID_0e4eRJu7SqhyjQSJn845lg)--



From owner-v6ops@ops.ietf.org  Fri Nov  5 01:43:15 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23704
	for <v6ops-archive@lists.ietf.org>; Fri, 5 Nov 2004 01:43:15 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CPxng-000Bzp-By
	for v6ops-data@psg.com; Fri, 05 Nov 2004 06:42:20 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CPxnf-000Bza-3q
	for v6ops@ops.ietf.org; Fri, 05 Nov 2004 06:42:19 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id iA56gEJ03506;
	Fri, 5 Nov 2004 08:42:15 +0200
Date: Fri, 5 Nov 2004 08:42:14 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: Ciprian Popoviciu <cpopovic@cisco.com>
cc: v6ops@ops.ietf.org, Salman Asadullah <sasad@cisco.com>,
        adeel Ahmed <adahmed@cisco.com>
Subject: Re: ISP IPv6 Deployment Scenarios in Broadband Access
In-Reply-To: <4.3.2.7.2.20041021152613.0257d200@fruitpie.cisco.com>
Message-ID: <Pine.LNX.4.61.0411050830580.3277@netcore.fi>
References: <4.3.2.7.2.20041021152613.0257d200@fruitpie.cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

Hi,

There's one thing that came across when doing the operator poll on v6 
deployment which might warrant more discussion in the document...

On Thu, 21 Oct 2004, Ciprian Popoviciu wrote:
> We integrated the feedback received on the first version of the "ISP IPv6 
> Deployment Scenarios in Broadband Access" draft and posted the updated 
> document. You can also find it at:
>
> [...]draft-asadullah-v6ops-bb-deployment-scenarios-01.txt
>
> We would like to thank Brian Carpenter, Patrick Grossetete, Benoit Lourdelet, 
> Tschofenig Hannes, Gert Doering,  Alexander Koch for their feedback and 
> particularly Pekka for all his help along with his feedback.

An operator which has deployed bridged-mode DSL ('RBE') said that the 
only solution for providing bulk v6 access at the moment is requiring 
the use of DHCPv6 for address assignment (i.e.: because DHCPv4 is 
snooped for v4, the vendors seem to have implemented the same kind of 
snooping for v6 w/ DHCPv6).

Needless to say that that sounds like a very big problem.  Requiring 
DHCPv6 for address assignment for something like this seems ludicurous 
at least :-).

Alternatives seem to be:
  1) defining each /64 prefix to advertise for each customer manually, 
not using bulk methods: this does not scale, so it's not an option.
  2) checking whether providing a single, shared /64 for all the 
customers would work (what if there are address conflicts?  what about 
communication inside the prefix?  does this work?)
  3) implementing a mechanism which would allow for direct mapping of 
VLAN or VC information to the advertised v6 prefix.  For example, so 
that for VLAN=100 you could just configure a bulk command 
'map-vlan-to-v6-prefix 2001:db8:1::/48', and it would hand out e.g. 
'2001:db8:1:64::/64' to the customer -- or something like that, 
allowing bulk configuration
  4) putting all the customers' v6 prefix information in a RADIUS or 
similar database, so that the advertisement information could be 
digged up from there.  A lot of work, and does not work automatically. 
This would also need some glue between bulk config and RADIUS.

All of this except 2) seems to be in the realm of implementations, not 
requiring IETF protocol modifications, but to get these features 
discussed and on the table, maybe such requirements and possible 
solutions should be described in the document.

Could someone check whether 2) is possible or not, and if yes, which 
kind of support it requires in the equipment ?

-- 
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 owner-v6ops@ops.ietf.org  Fri Nov  5 01:47:28 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23937
	for <v6ops-archive@lists.ietf.org>; Fri, 5 Nov 2004 01:47:28 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CPxsO-000CZT-Ch
	for v6ops-data@psg.com; Fri, 05 Nov 2004 06:47:12 +0000
Received: from [192.18.98.36] (helo=brmea-mail-4.sun.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CPxsN-000CZ8-BF
	for v6ops@ops.ietf.org; Fri, 05 Nov 2004 06:47:11 +0000
Received: from esunmail ([129.147.156.34])
	by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id iA56lBNH012381
	for <v6ops@ops.ietf.org>; Thu, 4 Nov 2004 23:47:11 -0700 (MST)
Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM
 (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTP id <0I6P002MH1IMBT@edgemail1.Central.Sun.COM> for
 v6ops@ops.ietf.org; Thu, 04 Nov 2004 23:47:10 -0700 (MST)
Received: from [192.168.1.2] ([66.93.39.75])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I6P00JUA1ILGV@mail.sun.net> for v6ops@ops.ietf.org; Thu,
 04 Nov 2004 23:47:10 -0700 (MST)
Date: Thu, 04 Nov 2004 22:47:08 -0800
From: Alain Durand <Alain.Durand@Sun.COM>
Subject: other comments on draft-nielsen-v6ops-3GPP-zeroconf-goals-00.txt
To: "'''IPv6 Operations ' ' '" <v6ops@ops.ietf.org>
Message-id: <835CE6EB-2EF6-11D9-AC14-00039376A6AA@sun.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.619)
Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Content-transfer-encoding: 7BIT
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7BIT

Direct tunneling:
-----------------------
I would have like this document to take a stance with regard to direct  
tunneling.
Is it needed or not? I found section 3.2 confusing:

 > 3.2. IPv6 tunnel link characteristics, Scope and Limitations:
 >
 >   Direct tunneling is neither an explicit goal nor explicitly excluded
 >   in Zero-Configuration Tunneling in the 3GPP network environment.

Specially when later, section 9.3 says:
 > 9.3. Implications of Direct Tunneling
 >
 >   In case direct tunneling in between end-hosts is provided by the
 >   tunneling protocol, it will not (as described in Section 9.2.1) be
 >   possibly for end-hosts to filter out received Protocol-41
 >   encapsulated packets based on whether the IPv4 source is an address
 >   belonging to a trusted Tunnel Server as such behavior evidently  
would
 >   break direct tunneling.
 >
 >   As other end-hosts generally are non-trusted, direct tunneling may
 >   thus open up for attacks against IPv6 ingress filtering.

The logical conclusion of section 9.3 seems to be that for security  
reasons,
direct tunneling should not be allowed and thus be a non goal of this  
document...
Unless, of course, there is a strong rationale for direct tunneling  
that should be spelled out
in section 3.2


Tunnel end-point discovery
-------------------------------------
This document should also reference
http://www.ietf.org/internet-drafts/draft-yamamoto-naptr-service- 
discovery-00.txt

No support for PAN
--------------------------
 > 3.1. IPv6 address allocation, Scope and Limitations:
 >
 >   The primary goal of 3GPP Zero-Configuration Tunneling is to provide
  >  IPv6 connectivity to nodes on an individual basis. By this it is
  >  meant that it is only an explicit goal to have a /128 address
  >  allocated for global connectivity on the tunnel link. As such  
optimal
  >  IPv6 connectivity provisioning in Personal Area Network (PAN)
  >  scenarios is not explicitly within the scope of Zero-Configuration
  >  Tunneling.

What does the phrase "optimal IPv6 connectivity provisioning in PAN"  
means?
The word 'optimal' confuses me...

I find this section a bit restrictive, as it is not difficult to design  
a zeroconf mechanism
that will enable prefix delegation with a simple router advertisement  
sent over the tunnel.
Also, this is a violation of RFC3177 which recommends allocation a /64  
to cell phone
especially in order to support PAN...
I would like to see at least better rationale why PAN support is not  
deemed important
or why it would introduce unjustifiable complexity.

Timing (section 5)
---------
Although I understand very well that time to market is the essence of  
this work
and this is good background information, section 5 should be removed  
from the final
document.

	- Alain.




From owner-v6ops@ops.ietf.org  Fri Nov  5 02:15:33 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10165
	for <v6ops-archive@lists.ietf.org>; Fri, 5 Nov 2004 02:15:32 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CPyIO-000Gl6-QQ
	for v6ops-data@psg.com; Fri, 05 Nov 2004 07:14:04 +0000
Received: from [192.18.98.36] (helo=brmea-mail-4.sun.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CPyIH-000Gk3-Vn
	for v6ops@ops.ietf.org; Fri, 05 Nov 2004 07:13:58 +0000
Received: from esunmail ([129.147.156.34])
	by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id iA57DvNH022466
	for <v6ops@ops.ietf.org>; Fri, 5 Nov 2004 00:13:57 -0700 (MST)
Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM
 (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTP id <0I6P002SW2R9BT@edgemail1.Central.Sun.COM> for
 v6ops@ops.ietf.org; Fri, 05 Nov 2004 00:13:57 -0700 (MST)
Received: from [192.168.1.2] ([66.93.39.75])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I6P00JQO2R7GS@mail.sun.net> for v6ops@ops.ietf.org; Fri,
 05 Nov 2004 00:13:56 -0700 (MST)
Date: Thu, 04 Nov 2004 23:13:54 -0800
From: Alain Durand <Alain.Durand@Sun.COM>
Subject: Re: A personal take on WG's priorities..
In-reply-to: <Pine.LNX.4.61.0411040837210.3699@netcore.fi>
To: Pekka Savola <pekkas@netcore.fi>
Cc: v6ops@ops.ietf.org
Message-id: <40D09F98-2EFA-11D9-AC14-00039376A6AA@sun.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.619)
Content-type: text/plain; charset=US-ASCII; format=flowed
Content-transfer-encoding: 7BIT
References: <Pine.LNX.4.61.0411040837210.3699@netcore.fi>
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7BIT

As you ask, here is my take on all this.

Essentially, there is work needed in 4 areas:

1. Tunneling
- finish the work on assisted tunneling, zeroconf tunneling, 3GPP 
tunneling requirements
- finish the analysis of existing protocol candidates
- design new one(s) if needed
- finish the work on tunnel end-point discovery

2. Protocol maintenance
- deprecate useless mechanism
- clarify/refine some mechanism (e.g. 6to4)
- move some mechanisms along standard track

3. Operational issues
- renumbering doc
- IPv6 on by default
- operational security docs
- result from operational experience

4.  Finish the work on scenario.

A natural evolution of NGtrans/v6ops would be to shut down v6Ops
by declaring victory on (4), and create two new working group,
a short to medium term one, focusing on (1) & (2), and a long  term one 
focusing on 3.

	- Alain.




From owner-v6ops@ops.ietf.org  Fri Nov  5 02:28:17 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11807
	for <v6ops-archive@lists.ietf.org>; Fri, 5 Nov 2004 02:28:17 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CPyVe-000INL-UH
	for v6ops-data@psg.com; Fri, 05 Nov 2004 07:27:46 +0000
Received: from [192.18.98.36] (helo=brmea-mail-4.sun.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CPyVe-000IN6-1l
	for v6ops@ops.ietf.org; Fri, 05 Nov 2004 07:27:46 +0000
Received: from esunmail ([129.147.156.34])
	by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id iA57RjNH027166
	for <v6ops@ops.ietf.org>; Fri, 5 Nov 2004 00:27:45 -0700 (MST)
Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM
 (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTP id <0I6P002IF3E9BT@edgemail1.Central.Sun.COM> for
 v6ops@ops.ietf.org; Fri, 05 Nov 2004 00:27:45 -0700 (MST)
Received: from [192.168.1.2] ([66.93.39.75])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I6P00LVY3E8OZ@mail.sun.net> for v6ops@ops.ietf.org; Fri,
 05 Nov 2004 00:27:45 -0700 (MST)
Date: Thu, 04 Nov 2004 23:27:43 -0800
From: Alain Durand <Alain.Durand@Sun.COM>
Subject: comments on draft-suryanarayanan-v6ops-zeroconf-reqs-01.txt
To: "'''IPv6 Operations ' ' '" <v6ops@ops.ietf.org>
Message-id: <2ED386DA-2EFC-11D9-AC14-00039376A6AA@sun.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.619)
Content-type: text/plain; charset=US-ASCII; format=flowed
Content-transfer-encoding: 7BIT
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7BIT

Similar to my comments on the 3GPP draft, this document should make
it clear if direct tunneling is a requirement or not and if yes, why.

	- Alain.




From owner-v6ops@ops.ietf.org  Fri Nov  5 03:55:19 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17292
	for <v6ops-archive@lists.ietf.org>; Fri, 5 Nov 2004 03:55:19 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CPzqw-00036G-38
	for v6ops-data@psg.com; Fri, 05 Nov 2004 08:53:50 +0000
Received: from [193.180.251.49] (helo=albatross.ericsson.se)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CPzqu-00035l-GX
	for v6ops@ops.ietf.org; Fri, 05 Nov 2004 08:53:48 +0000
Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121])
	by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id iA58rlvD025093
	for <v6ops@ops.ietf.org>; Fri, 5 Nov 2004 09:53:47 +0100 (MET)
Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211);
	 Fri, 5 Nov 2004 09:53:45 +0100
Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id WB15LM9G; Fri, 5 Nov 2004 09:53:45 +0100
Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <VJQGN1W0>; Fri, 5 Nov 2004 09:53:45 +0100
Message-ID: <C26BB8276599A44B85D52F9CE41035E1050B9803@esealnt944.al.sw.ericsson.se>
X-Sybari-Trust: 25737995 8cefd49f 6c1fa2a8 00000138
From: "Karen E. Nielsen (AH/LMD)" <karen.e.nielsen@ericsson.com>
To: "'Bound, Jim'" <jim.bound@hp.com>, v6ops@ops.ietf.org
Subject: RE: Comments: draft-nielsen-v6ops-3GPP-zeroconf-goals-00.txt
Date: Fri, 5 Nov 2004 09:53:42 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
X-OriginalArrivalTime: 05 Nov 2004 08:53:45.0765 (UTC) FILETIME=[F56EAD50:01C4C314]
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

Hi Jim,

Thanks.

> The spec once it speaks about tunneling is all over the place 
> saying it
> can support private addresses, NATs etc.
> 

The spec explicitly does not specify NAT traversal.
It does speak about supporting private and dynamically allocated IPv4 addresses, but
that does not necessarily involve NAT traversal and in our case [the 3gpp case]
it doesn't, as the assumption is
"There are no NATs in between the tunnel endpoints in the Zero-
        Configuration Tunnelling site."
or in other words if you like,
the tunnel server and the tunnel client are located within the same logical Ipv4 network.


> http://www.ietf.org/internet-drafts/draft-nielsen-v6ops-3GPP-z
> eroconf-go
> als-00.txt
> 
> I think some of this is just impossible for mobility.  A real case in
> S.E. Asia right now looking at 3G IPv6 deployment has the following
> problem.  Mobile (seamless) nodes will use native IPv6 and IPv4 to get
> to legacy apps that have not been ported to IPv6.  In this case the
> problem is that public IPv4 addresses are needed.  But we 
> know all that
> and we must address that case.  The other case is that to get 
> to the IMS
> networks first you havce to tunnel the packet through IPv4 network to
> IMS IPv6 network.  This is not going to work with NAT when the user is
> roaming.  So I don't see why the spec does not say this.
> 

The reason the spec doesn't speak about these cases is because
it consider the 3gpp Ipv6 in Ipv4 tunelling case only.

In the 3gpp situation then when the user is roaming it will maintain the pdp context 
- logical IP link - towards its home operator. Yes it is not very effective routing wise, but this is the 
situation.              

> Hence, my first input to this spec (and I do believe it should be WG
> item) is that we will need to discuss deployment profiles for mobility
> and more of enterprise nature than 3GPP nature.  
> 

The more general 3G deployment cases, that you point to, are
equally important to consider, I agree. This simply wasn't the scope of this document.
That may be changed of course - Or the non-3gpp cases may be treated in the general zero-conf
document:
http://www.v6ops.euro6ix.net/ietf/draft-suryanarayanan-v6ops-zeroconf-reqs-01.txt

BR, Karen

> Thanks
> /jim
> 
> 



From owner-v6ops@ops.ietf.org  Fri Nov  5 05:25:55 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26742
	for <v6ops-archive@lists.ietf.org>; Fri, 5 Nov 2004 05:25:54 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CQ1Gl-000GKQ-TM
	for v6ops-data@psg.com; Fri, 05 Nov 2004 10:24:35 +0000
Received: from [195.212.29.136] (helo=mtagate3.uk.ibm.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CQ1GT-000GHr-8M
	for v6ops@ops.ietf.org; Fri, 05 Nov 2004 10:24:17 +0000
Received: from d06nrmr1507.portsmouth.uk.ibm.com (d06nrmr1507.portsmouth.uk.ibm.com [9.149.38.233])
	by mtagate3.uk.ibm.com (8.12.10/8.12.10) with ESMTP id iA5AO5eg172408;
	Fri, 5 Nov 2004 10:24:05 GMT
Received: from sihl.zurich.ibm.com (d06av03.portsmouth.uk.ibm.com [9.149.37.213])
	by d06nrmr1507.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iA5AO3m1038784;
	Fri, 5 Nov 2004 10:24:04 GMT
Received: from zurich.ibm.com (sig-9-145-250-206.de.ibm.com [9.145.250.206])
	by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA84242;
	Fri, 5 Nov 2004 11:24:02 +0100
Message-ID: <418B54BF.1070508@zurich.ibm.com>
Date: Fri, 05 Nov 2004 11:23:59 +0100
From: Brian E Carpenter <brc@zurich.ibm.com>
Organization: IBM
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en, fr, de
MIME-Version: 1.0
To: Liu Min <liumin@ict.ac.cn>
CC: "'Sham Chakravorty'" <schakra@mitre.org>, v6ops@ops.ietf.org
Subject: Flow label and Traffic Class [Re: A personal take on WG's priorities..]
References: <000701c4c2e6$5fa65760$4b74a8c0@ThinkPadX31>
In-Reply-To: <000701c4c2e6$5fa65760$4b74a8c0@ThinkPadX31>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Liu Min wrote:
> I also want to know if we want to make some suggestion or present some
> proposal for IPv6 Flow Label, where should we do it. When we introduce IPv6,
> the Flow Label and Traffic Class, and its support for QoS are always one
> topic. However, you can not present a QoS mechanism or a network measurement
> tool using Flow Label and Traffic Class, because they are still experimental
> and subject to change. 

This last sentence is not correct. The Traffic Class is Proposed Standard
(RFC 2474, RFC 2597, RFC 3246, RFC 3289 and others). It is operational in
IPv4, and will operate identically in IPv6.

The Flow Label general rules are Proposed Standard (RFC 3697; also see
RFC 3595). However, we still need to describe specific use cases for the
Flow Label. That is the work that needs to be done, and anyone can
publish an I-D describing a use case, and ask for a BOF.

    Brian

> 
>  
> Best Wishes,
>  
> 
> Liu Min
>  
> Institute of Computing Technology
> Chinese Academy of Sciences
> Tel: (86-10) 6256 5533-9240 
> E-mail: liumin@ict.ac.cn
> 
> 
> 
>>-----Original Message-----
>>From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf
>>Of Sham Chakravorty
>>Sent: Thursday, November 04, 2004 9:24 PM
>>To: v6ops@ops.ietf.org
>>Subject: RE: A personal take on WG's priorities..
>>
>>In this regard, would it make sense to add IPv6 Flow Label usage in a
>>"sub-WG" area such as Enterprise or IPv6 Traffic Modeling?  One would
> 
> think
> 
>>this is one of the  key IPv6 operations areas.  It seems to me we are
>>focused only in a few, narrowly focused areas of IPv6 operations (as
>>reflected in the charter).
>>
>>Sham Chakravorty
>>
>>-----Original Message-----
>>From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf
>>Of EricLKlein
>>Sent: Thursday, November 04, 2004 3:30 AM
>>To: v6ops@ops.ietf.org
>>Subject: Re: A personal take on WG's priorities..
>>
>>
>>From: "Brian
>>
>>>Quite obviously, it would be outrageous to attempt all this
>>>in one WG. IMHO, we need to either out-source work to other
>>>WGs or create several new WGs with focussed charters.
>>>Especially, we need to separate "getting known stuff
>>>fully operational" from "doing new stuff."
>>
>>Is it possible to try to set up "sub-WG" areas and recruit more
> 
> specialized
> 
>>people into these areas?
>>
>>I am thinking (of the top of my head) of three subgroups:
>>- Enterprise - would include migration issues, etc.
>>- ISPs - would handle tunnels, interconnections, etc
>>- IPv6 Security - would handle NAT-PT, depreciating NAT in IPv6, etc.
>>
>>Just a thought.
>>Eric
>>
>>
>>
>>
>>
>>
> 
> 
> 
> 
> 
> 



From owner-v6ops@ops.ietf.org  Fri Nov  5 05:41:12 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28601
	for <v6ops-archive@lists.ietf.org>; Fri, 5 Nov 2004 05:41:12 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CQ1WE-000Ibr-Qt
	for v6ops-data@psg.com; Fri, 05 Nov 2004 10:40:34 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CQ1WA-000IaO-Jv
	for v6ops@ops.ietf.org; Fri, 05 Nov 2004 10:40:31 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id iA5AeRd09239;
	Fri, 5 Nov 2004 12:40:27 +0200
Date: Fri, 5 Nov 2004 12:40:27 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: Alain Durand <Alain.Durand@Sun.COM>
cc: v6ops@ops.ietf.org
Subject: Re: A personal take on WG's priorities..
In-Reply-To: <40D09F98-2EFA-11D9-AC14-00039376A6AA@sun.com>
Message-ID: <Pine.LNX.4.61.0411051236240.9025@netcore.fi>
References: <Pine.LNX.4.61.0411040837210.3699@netcore.fi>
 <40D09F98-2EFA-11D9-AC14-00039376A6AA@sun.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

On Thu, 4 Nov 2004, Alain Durand wrote:
> Essentially, there is work needed in 4 areas:
>
> 1. Tunneling
> - finish the work on assisted tunneling, zeroconf tunneling, 3GPP tunneling 
> requirements
> - finish the analysis of existing protocol candidates
> - design new one(s) if needed
> - finish the work on tunnel end-point discovery
>
> 2. Protocol maintenance
> - deprecate useless mechanism
> - clarify/refine some mechanism (e.g. 6to4)
> - move some mechanisms along standard track
>
> 3. Operational issues
> - renumbering doc
> - IPv6 on by default
> - operational security docs
> - result from operational experience
>
> 4.  Finish the work on scenario.
>
> A natural evolution of NGtrans/v6ops would be to shut down v6Ops
> by declaring victory on (4), and create two new working group,
> a short to medium term one, focusing on (1) & (2), and a long  term one 
> focusing on 3.

1 and 2 are certainly separable pieces of this puzzle.  However, it is 
important to put in place good policies on which kind of new tunneling 
work would be accepted (would it e.g., require a rechartering) so that 
the "v6mechs" WG would not become a "swamp".

3 and 4 are something that could be doable by "trimmed-down" v6ops; 
I'd see no particular use in shutting down a WG and springing up a new 
one in its place.  (4) needs to be finished, and there might be useful 
work coming down at that pipe down the road (like the BB ISP 
document).  I don't think the WG would need to initiate actively new 
work on 4, but if there were solid proposals on better documentation 
of existing scenarios, I don't see why that could not be documented.

-- 
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 owner-v6ops@ops.ietf.org  Fri Nov  5 07:05:30 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04903
	for <v6ops-archive@lists.ietf.org>; Fri, 5 Nov 2004 07:05:29 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CQ2oq-0004X0-I8
	for v6ops-data@psg.com; Fri, 05 Nov 2004 12:03:52 +0000
Received: from [193.180.251.53] (helo=eagle.ericsson.se)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CQ2oi-0004W3-FA
	for v6ops@ops.ietf.org; Fri, 05 Nov 2004 12:03:44 +0000
Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120])
	by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id iA5C3hR2032105
	for <v6ops@ops.ietf.org>; Fri, 5 Nov 2004 13:03:43 +0100
Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211);
	 Fri, 5 Nov 2004 13:03:43 +0100
Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id WFZH1KCH; Fri, 5 Nov 2004 13:03:43 +0100
Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <J4ND1T2Y>; Fri, 5 Nov 2004 13:03:43 +0100
Message-ID: <C26BB8276599A44B85D52F9CE41035E1050B9805@esealnt944.al.sw.ericsson.se>
X-Sybari-Trust: e643b375 ad48f3dd edabb938 00000179
From: "Karen E. Nielsen (AH/LMD)" <karen.e.nielsen@ericsson.com>
To: "'Alain Durand'" <Alain.Durand@Sun.COM>,
        "'''IPv6 Operations ' ' '"
	 <v6ops@ops.ietf.org>
Subject: RE: other comments on draft-nielsen-v6ops-3GPP-zeroconf-goals-00.
	txt
Date: Fri, 5 Nov 2004 13:03:37 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
X-OriginalArrivalTime: 05 Nov 2004 12:03:43.0277 (UTC) FILETIME=[7EE0FDD0:01C4C32F]
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

Hi Alain,

Thanks a lot for your comments.

> -----Original Message-----
> From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On
> Behalf Of Alain Durand
> Sent: Friday, November 05, 2004 7:47 AM
> To: '''IPv6 Operations ' ' '
> Subject: other comments on
> draft-nielsen-v6ops-3GPP-zeroconf-goals-00.txt
> 
> 
> Direct tunneling:
> -----------------------
> I would have like this document to take a stance with regard 
> to direct  
> tunneling.
> Is it needed or not? I found section 3.2 confusing:
> 
>  > 3.2. IPv6 tunnel link characteristics, Scope and Limitations:
>  >
>  >   Direct tunneling is neither an explicit goal nor 
> explicitly excluded
>  >   in Zero-Configuration Tunneling in the 3GPP network environment.
> 
> Specially when later, section 9.3 says:
>  > 9.3. Implications of Direct Tunneling
>  >
>  >   In case direct tunneling in between end-hosts is provided by the
>  >   tunneling protocol, it will not (as described in Section 
> 9.2.1) be
>  >   possibly for end-hosts to filter out received Protocol-41
>  >   encapsulated packets based on whether the IPv4 source is 
> an address
>  >   belonging to a trusted Tunnel Server as such behavior evidently  
> would
>  >   break direct tunneling.
>  >
>  >   As other end-hosts generally are non-trusted, direct 
> tunneling may
>  >   thus open up for attacks against IPv6 ingress filtering.
> 
> The logical conclusion of section 9.3 seems to be that for security  
> reasons,
> direct tunneling should not be allowed and thus be a non goal 
> of this  
> document...
> Unless, of course, there is a strong rationale for direct tunneling  
> that should be spelled out
> in section 3.2
> 
> 

The situation in my mind in the following:

No, direct tunnelling is not a prerequiste.
But, if direct tunnelling is provided in a secure way, then why not.

As you have pointed out this could be said more clearly in the doc.
If people disagrees with allowing secure direct tunnelling, then it will
have to be changed altogether, of course. 

> Tunnel end-point discovery
> -------------------------------------
> This document should also reference
> http://www.ietf.org/internet-drafts/draft-yamamoto-naptr-service- 
> discovery-00.txt
> 

Yes, now it should. Thanks.
Let me and the other authors think about how it should be put exactly, I have a 
small concern with this in the 3gpp environment due to RT delays (more or that to come).

> No support for PAN
> --------------------------
>  > 3.1. IPv6 address allocation, Scope and Limitations:
>  >
>  >   The primary goal of 3GPP Zero-Configuration Tunneling is 
> to provide
>   >  IPv6 connectivity to nodes on an individual basis. By this it is
>   >  meant that it is only an explicit goal to have a /128 address
>   >  allocated for global connectivity on the tunnel link. As such  
> optimal
>   >  IPv6 connectivity provisioning in Personal Area Network (PAN)
>   >  scenarios is not explicitly within the scope of 
> Zero-Configuration
>   >  Tunneling.
> 
> What does the phrase "optimal IPv6 connectivity provisioning in PAN"  
> means?
> The word 'optimal' confuses me...
> 

Well you may support a PAN by allocating each of devices in the PAN
a seperate address and its own tunnel for external communication. They will
not get a /64 prefix to share however.

They may communicate with each other using the tunnels to the tunnel server
(thats where the unoptimal) comes from. They may also of course commmunicate
internally using some ad hoc routing protocols but the PAN cannot be based
on simpel lan (one one-link prefix) communication.


> I find this section a bit restrictive, as it is not difficult 
> to design  
> a zeroconf mechanism
> that will enable prefix delegation with a simple router 
> advertisement  
> sent over the tunnel.
> Also, this is a violation of RFC3177 which recommends 
> allocation a /64  
> to cell phone
> especially in order to support PAN...
> I would like to see at least better rationale why PAN support is not  
> deemed important
> or why it would introduce unjustifiable complexity.
> 

I don't think that it is a problem per se that a transistion mechanisms
doesn't provide what native IP does. Specifically it is not a problem
per se that the address provisioning of a transition mechanism isn't 
in compliance with RFC3177.

It is a problem, of course, if the transition mechanism does not support the deployment
scenarios that it is envisaged for. In the 3gpp environment, PAN applications aren't like
the first IPv6 applications that one are looking to pilot and as such no one have
come forward with requirements for the tunnelling mechanism to support the PAN scenario.
- Consequently when looking for the minimal set of requirements, it has not been found worthwhile 
to bind the solution to support the PAN scenario, also.

Note that there are a lot of applications, much more in focus than the PAN scenario,
that the tunnelling mechanism cannot solve anyway due to the dependence on various 
intrinsic 3gpp functions which won't support the transistion scenario.

With respect to the complexity issues of introducing prefix delegation, I will take the liberty
to repeat once more that we have tried to stick to the requirements of the deployment scenarios
and have not introduced something as a requirement simple because it was considered feasible. 

Don't take me worng, I agree that this is not a simple "black and white" issue.


> Timing (section 5)
> ---------
> Although I understand very well that time to market is the 
> essence of  
> this work
> and this is good background information, section 5 should be removed  
> from the final
> document.
> 

I agree.

Right now it is there, also to emphasize why the "3gpp people" (as Pekka
terms us, I think) were reluctant to broaded the scope of the document with the risk
of introducing additional delays.

BR, Karen

> 	- Alain.
> 
> 



From owner-v6ops@ops.ietf.org  Fri Nov  5 08:40:17 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12531
	for <v6ops-archive@lists.ietf.org>; Fri, 5 Nov 2004 08:40:17 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CQ4Hd-000Huj-5A
	for v6ops-data@psg.com; Fri, 05 Nov 2004 13:37:41 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CQ4HY-000HuC-VX
	for v6ops@ops.ietf.org; Fri, 05 Nov 2004 13:37:37 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id iA5DbSG13639;
	Fri, 5 Nov 2004 15:37:28 +0200
Date: Fri, 5 Nov 2004 15:37:28 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: "Karen E. Nielsen (AH/LMD)" <karen.e.nielsen@ericsson.com>
cc: "'Alain Durand'" <Alain.Durand@Sun.COM>,
        "'''IPv6 Operations ' ' '" <v6ops@ops.ietf.org>
Subject: RE: other comments on draft-nielsen-v6ops-3GPP-zeroconf-goals-00.
 txt
In-Reply-To: <C26BB8276599A44B85D52F9CE41035E1050B9805@esealnt944.al.sw.ericsson.se>
Message-ID: <Pine.LNX.4.61.0411051531090.13462@netcore.fi>
References: <C26BB8276599A44B85D52F9CE41035E1050B9805@esealnt944.al.sw.ericsson.se>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

One comment on a comment,

On Fri, 5 Nov 2004, Karen E. Nielsen (AH/LMD) wrote:
>> Tunnel end-point discovery
>> -------------------------------------
>> This document should also reference
>> http://www.ietf.org/internet-drafts/draft-yamamoto-naptr-service-
>> discovery-00.txt
>>
>
> Yes, now it should. Thanks.
>
> Let me and the other authors think about how it should be put 
> exactly, I have a small concern with this in the 3gpp environment 
> due to RT delays (more or that to come).

Let me disagree here, rather strongly.

The requirements document like this should not point at various 
solutions documents.  In the case of tunnel endpoint discovery, we 
have a good document (draft-palet-v6ops-tun-auto-disc-00.txt) -- which 
could include more discussion relating to draft-yamamoto-, but there 
is no need to refer to that *HERE*.

However, as there are a *LOT* of different tradeoffs regarding tunnel 
end-point discovery, it makes sense to elaborate a bit on the 
tradeoffs of 3GPP.  For example, whether DHCP could be used (I think 
not); whether DNS lookups are feasible; how many round-trips should be 
the maximum; whether this could be piggybacked on a 3GPP configuration 
protocol; whether the mechanism should fail gracefully (and after how 
many attempts) if the service is not found; etc.

-- 
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 owner-v6ops@ops.ietf.org  Fri Nov  5 09:31:00 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16204
	for <v6ops-archive@lists.ietf.org>; Fri, 5 Nov 2004 09:30:59 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CQ564-000OdP-EW
	for v6ops-data@psg.com; Fri, 05 Nov 2004 14:29:48 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CQ563-000Ocz-15
	for v6ops@ops.ietf.org; Fri, 05 Nov 2004 14:29:47 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id iA5ETju15124
	for <v6ops@ops.ietf.org>; Fri, 5 Nov 2004 16:29:45 +0200
Date: Fri, 5 Nov 2004 16:29:45 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: v6ops@ops.ietf.org
Subject: BOUNCE v6ops@ops.ietf.org:    Non-member submission from
 [=?iso-8859-1?Q?R=E9mi_Despr=E9s?= <remi.despres@rd-iptech.com>]    (fwd)
Message-ID: <Pine.LNX.4.61.0411051629270.14925@netcore.fi>
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="1589707168-1483850525-1099664985=:14925"
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--1589707168-1483850525-1099664985=:14925
Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8BIT

Approved: ops
>From remi.despres@rd-iptech.com Fri Nov 05 12:34:16 2004
Received: from [193.252.22.29] (helo=mwinf0203.wanadoo.fr)
 	by psg.com with esmtp (Exim 4.41 (FreeBSD))
 	id 1CQ3IF-0008lF-UX
 	for v6ops@ops.ietf.org; Fri, 05 Nov 2004 12:34:16 +0000
Received: from me-wanadoo.net (localhost [127.0.0.1])
 	by mwinf0203.wanadoo.fr (SMTP Server) with SMTP
 	id BF32F100008F; Fri,  5 Nov 2004 13:34:14 +0100 (CET)
Received: from Rmi (APuteaux-105-1-3-243.w80-11.abo.wanadoo.fr [80.11.85.243])
 	by mwinf0203.wanadoo.fr (SMTP Server) with SMTP
 	id 24556100008E; Fri,  5 Nov 2004 13:34:14 +0100 (CET)
Message-ID: <006e01c4c333$c29ec530$0200a8c0@Rmi>
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= <remi.despres@rd-iptech.com>
To: <jordi.palet@consulintel.es>, <v6ops@ops.ietf.org>
References: <BDB07704.4DFB1%jordi.palet@consulintel.es>
Subject: Re: A personal take on WG's priorities..
Date: Fri, 5 Nov 2004 13:34:12 +0100
MIME-Version: 1.0
Content-Type: text/plain;
 	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Level:
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham
 	version=2.64

Jordi, Jim, Pekka,

As explained in http://perso.wanadoo.fr/remi.despres/4to6.htm there seems to
be important missing pieces for a number of desirable transition
configurations, with possible solutions to satisfy these needs.
IMHO, some group work somehere on the subject should  be possible.

Rémi

----- Original Message -----
From: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>
To: <v6ops@ops.ietf.org>
Sent: Friday, November 05, 2004 12:17 AM
Subject: Re: A personal take on WG's priorities..


Jim,

My view is that we should only work in new transition mechanism if there is
something _really_ not covered already, but we also should work on those "de
facto" mechanism to get standardized if it make sense.

Regards,
Jordi

> De: "Bound, Jim" <jim.bound@hp.com>
> Responder a: owner-v6ops@ops.ietf.org
> Fecha: Thu, 4 Nov 2004 13:10:57 -0500
> Para: "Brian E Carpenter" <brc@zurich.ibm.com>,
<jordi.palet@consulintel.es>
> CC: <v6ops@ops.ietf.org>
> Asunto: RE: A personal take on WG's priorities..
>
> But I don't agree we should not work on new emerging transition mechanisms
> that in fact are being deployed as we talk here.
> /jim
>>>> Pekka Savola wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Based on the discussion on what the WG should be doing, I
>> cooked up
>>>>> my
>>>>> **personal** list of what I consider to be priorities, in
>> some rough
>>>>> categories.  As you see, there's a *LOT* that falls under the WG
>>>>> charter, and there is no way we could work on even 1/3 or 1/4 of
>>>>> these at the same time.  So, there must be some priorization.
>>>>>
>>>>> I welcome comments especially if you think I've badly
>> misprioritized
>>>>> document/work that relates to the v6ops charter.
>>>>>
>>>>> ======
>>>>>
>>>>> The most important work
>>>>> - finish enterprise analysis
>>>>> - finish requirement(s) for tunneling
>>>>>    * to be able to decide whether existing solution(s)
>> are sufficient
>>>>>      and if not, get started on specifying new ones
>>>>> - get started on mechanisms (somewhere else?) if needed/necessary
>>>>>
>>>>> Pretty darn important work
>>>>> - the last spin at 3GPP analysis doc, updated IMS scenario
>>>>> - better document the ISP's broadband transition scenarios
>>>>>    * draft-asadullah-v6ops-bb-deployment-scenarios-01
>>>>> - finish draft-ietf-v6ops-mech-v2
>>>>>    * waiting for feedback from the IESG telechat..
>>>>> - adopt and finish draft-tschofenig-v6ops-secure-tunnels-02.txt
>>>>>    * IESG requirement for draft-ietf-v6ops-mech-v2
>>>>> - figure what to do about the NAT-PT deprecation/analysis
>>>>>   *  draft-aoun-v6ops-natpt-deprecate
>>>>> - (techno-political) document for v4 NAT users
>>>>>   * draft-vandevelde-v6ops-nap
>>>>> - IPv6-on-by-default work, fixes need to be integrated in
>> the IETF work
>>>>>   * draft-ietf-v6ops-onlinkassumption
>>>>>   * draft-ietf-v6ops-v6onbydefault
>>>>>   * etc.
>>>>>
>>>>> Important work
>>>>> - draft-ietf-v6ops-renumbering-procedure
>>>>>   * needs revision to address IESG comments
>>>>> - draft-palet-v6ops-tun-auto-disc
>>>>> - draft-chown-v6ops-vlan-usage
>>>>> - figuring out how to deal with Mobile IP transition issues
>>>>> - security overview of IPv6
>>>>>    * draft-savola-v6ops-security-overview
>>>>>
>>>>> Useful work
>>>>> - revising 6to4 spec to be clearer, etc.
>>>>> - draft-palet-v6ops-solution-tun-auto-disc
>>>>> - draft-chown-v6ops-renumber-thinkabout-00
>>>>> - draft-chown-v6ops-port-scanning-implications
>>>>>
>>>>> Difficult to say whether it has gained sufficient
>> momentum, and/or
>>>>> whether this is the right place to do this
>>>>> - draft-palet-v6ops-auto-trans
>>>>> - draft-palet-v6ops-ipv6security
>>>>> - draft-vives-v6ops-ipv6-security-ps
>>>>> - draft-kondo-quarantine-overview-01.txt
>>>>>
>>>>> Not sure whether it should be published as RFC, or is sufficiently
>>>>> relevant
>>>>> - draft-chown-v6ops-campus-transition
>>>>> - draft-morelli-v6ops-ipv6-ix
>>>>>

--1589707168-1483850525-1099664985=:14925--



From owner-v6ops@ops.ietf.org  Fri Nov  5 11:32:35 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26497
	for <v6ops-archive@lists.ietf.org>; Fri, 5 Nov 2004 11:32:34 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CQ6zB-000HCC-Ba
	for v6ops-data@psg.com; Fri, 05 Nov 2004 16:30:49 +0000
Received: from [213.172.48.142] (helo=consulintel.es)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CQ6yz-000HAz-5h
	for v6ops@ops.ietf.org; Fri, 05 Nov 2004 16:30:37 +0000
Received: from [10.0.0.156] by consulintel.es
	(MDaemon.PRO.v7.2.0.R)
	with ESMTP id md50000561076.msg
	for <v6ops@ops.ietf.org>; Fri, 05 Nov 2004 17:36:06 +0100
User-Agent: Microsoft-Entourage/10.1.4.030702.0
Date: Fri, 05 Nov 2004 17:30:29 +0100
Subject: Re: other comments on draft-nielsen-v6ops-3GPP-zeroconf-goals-00.
	txt
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: <v6ops@ops.ietf.org>
Message-ID: <BDB16935.4E3CE%jordi.palet@consulintel.es>
In-Reply-To: <Pine.LNX.4.61.0411051531090.13462@netcore.fi>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Spam-Processed: consulintel.es, Fri, 05 Nov 2004 17:36:06 +0100
	(not processed: message from valid local sender)
X-MDRemoteIP: 10.0.0.156
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ops.ietf.org
Reply-To: jordi.palet@consulintel.es
X-MDAV-Processed: consulintel.es, Fri, 05 Nov 2004 17:36:07 +0100
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Pekka,

You mean including in the next version of draft-palet-v6ops-tun-auto-disc
something specific to 3GPP considerations ?

No problem in doing that. Will try to work on this next week, but can't
promise being so fast this time !

Also, we have already some text regarding NAPTR, but we can expand if
required. Any specific suggestion or text that someone want to propose ?

Regards,
Jordi



> De: Pekka Savola <pekkas@netcore.fi>
> Responder a: owner-v6ops@ops.ietf.org
> Fecha: Fri, 5 Nov 2004 15:37:28 +0200 (EET)
> Para: "Karen E. Nielsen (AH/LMD)" <karen.e.nielsen@ericsson.com>
> CC: "'Alain Durand'" <Alain.Durand@Sun.COM>, "'''IPv6 Operations ' ' '"
> <v6ops@ops.ietf.org>
> Asunto: RE: other comments on draft-nielsen-v6ops-3GPP-zeroconf-goals-00. txt
> 
> One comment on a comment,
> 
> On Fri, 5 Nov 2004, Karen E. Nielsen (AH/LMD) wrote:
>>> Tunnel end-point discovery
>>> -------------------------------------
>>> This document should also reference
>>> http://www.ietf.org/internet-drafts/draft-yamamoto-naptr-service-
>>> discovery-00.txt
>>> 
>> 
>> Yes, now it should. Thanks.
>> 
>> Let me and the other authors think about how it should be put
>> exactly, I have a small concern with this in the 3gpp environment
>> due to RT delays (more or that to come).
> 
> Let me disagree here, rather strongly.
> 
> The requirements document like this should not point at various
> solutions documents.  In the case of tunnel endpoint discovery, we
> have a good document (draft-palet-v6ops-tun-auto-disc-00.txt) -- which
> could include more discussion relating to draft-yamamoto-, but there
> is no need to refer to that *HERE*.
> 
> However, as there are a *LOT* of different tradeoffs regarding tunnel
> end-point discovery, it makes sense to elaborate a bit on the
> tradeoffs of 3GPP.  For example, whether DHCP could be used (I think
> not); whether DNS lookups are feasible; how many round-trips should be
> the maximum; whether this could be piggybacked on a 3GPP configuration
> protocol; whether the mechanism should fail gracefully (and after how
> many attempts) if the service is not found; etc.
> 
> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> 
> 



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






From owner-v6ops@ops.ietf.org  Fri Nov  5 11:52:38 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28053
	for <v6ops-archive@lists.ietf.org>; Fri, 5 Nov 2004 11:52:37 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CQ7JK-000KTq-4I
	for v6ops-data@psg.com; Fri, 05 Nov 2004 16:51:38 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CQ7JI-000KTN-Dy
	for v6ops@ops.ietf.org; Fri, 05 Nov 2004 16:51:37 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id iA5GpXA18438
	for <v6ops@ops.ietf.org>; Fri, 5 Nov 2004 18:51:33 +0200
Date: Fri, 5 Nov 2004 18:51:33 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: v6ops@ops.ietf.org
Subject: Re: BOUNCE v6ops@ops.ietf.org:    Non-member submission from
 [=?iso-8859-1?Q?R=E9mi_Despr=E9s?= <remi.despres@rd-iptech.com>]    (fwd)
In-Reply-To: <Pine.LNX.4.61.0411051629270.14925@netcore.fi>
Message-ID: <Pine.LNX.4.61.0411051851050.18349@netcore.fi>
References: <Pine.LNX.4.61.0411051629270.14925@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

On Fri, 5 Nov 2004, Pekka Savola wrote:

oops :)  sorry for fat fingers when posting the non-subscriber mails..

-- 
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 owner-v6ops@ops.ietf.org  Fri Nov  5 11:56:04 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28282
	for <v6ops-archive@lists.ietf.org>; Fri, 5 Nov 2004 11:56:04 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CQ7NL-000LLg-2y
	for v6ops-data@psg.com; Fri, 05 Nov 2004 16:55:47 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CQ7NG-000LKw-I7
	for v6ops@ops.ietf.org; Fri, 05 Nov 2004 16:55:43 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id iA5GtfI18552
	for <v6ops@ops.ietf.org>; Fri, 5 Nov 2004 18:55:41 +0200
Date: Fri, 5 Nov 2004 18:55:41 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: v6ops@ops.ietf.org
Subject: BOUNCE v6ops@ops.ietf.org:    Non-member submission from
 [=?iso-8859-1?Q?R=E9mi_Despr=E9s?= <remi.despres@rd-iptech.com>]    (fwd)
Message-ID: <Pine.LNX.4.61.0411051854200.18349@netcore.fi>
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="1589707168-877944872-1099673674=:18349"
Content-ID: <Pine.LNX.4.61.0411051854460.18349@netcore.fi>
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--1589707168-877944872-1099673674=:18349
Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1; FORMAT=flowed
Content-ID: <Pine.LNX.4.61.0411051854461.18349@netcore.fi>
Content-Transfer-Encoding: 8BIT

Approved: drops
>From remi.despres@rd-iptech.com Fri Nov 05 12:34:16 2004
Received: from [193.252.22.29] (helo=mwinf0203.wanadoo.fr)
 	by psg.com with esmtp (Exim 4.41 (FreeBSD))
 	id 1CQ3IF-0008lF-UX
 	for v6ops@ops.ietf.org; Fri, 05 Nov 2004 12:34:16 +0000
Received: from me-wanadoo.net (localhost [127.0.0.1])
 	by mwinf0203.wanadoo.fr (SMTP Server) with SMTP
 	id BF32F100008F; Fri,  5 Nov 2004 13:34:14 +0100 (CET)
Received: from Rmi (APuteaux-105-1-3-243.w80-11.abo.wanadoo.fr [80.11.85.243])
 	by mwinf0203.wanadoo.fr (SMTP Server) with SMTP
 	id 24556100008E; Fri,  5 Nov 2004 13:34:14 +0100 (CET)
Message-ID: <006e01c4c333$c29ec530$0200a8c0@Rmi>
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= <remi.despres@rd-iptech.com>
To: <jordi.palet@consulintel.es>, <v6ops@ops.ietf.org>
References: <BDB07704.4DFB1%jordi.palet@consulintel.es>
Subject: Re: A personal take on WG's priorities..
Date: Fri, 5 Nov 2004 13:34:12 +0100
MIME-Version: 1.0
Content-Type: text/plain;
 	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Level:
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham
 	version=2.64

Jordi, Jim, Pekka,

As explained in http://perso.wanadoo.fr/remi.despres/4to6.htm there seems to
be important missing pieces for a number of desirable transition
configurations, with possible solutions to satisfy these needs.
IMHO, some group work somehere on the subject should  be possible.

Rémi

----- Original Message -----
From: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>
To: <v6ops@ops.ietf.org>
Sent: Friday, November 05, 2004 12:17 AM
Subject: Re: A personal take on WG's priorities..


Jim,

My view is that we should only work in new transition mechanism if there is
something _really_ not covered already, but we also should work on those "de
facto" mechanism to get standardized if it make sense.

Regards,
Jordi

> De: "Bound, Jim" <jim.bound@hp.com>
> Responder a: owner-v6ops@ops.ietf.org
> Fecha: Thu, 4 Nov 2004 13:10:57 -0500
> Para: "Brian E Carpenter" <brc@zurich.ibm.com>,
<jordi.palet@consulintel.es>
> CC: <v6ops@ops.ietf.org>
> Asunto: RE: A personal take on WG's priorities..
>
> But I don't agree we should not work on new emerging transition mechanisms
> that in fact are being deployed as we talk here.
> /jim
>>>> Pekka Savola wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Based on the discussion on what the WG should be doing, I
>> cooked up
>>>>> my
>>>>> **personal** list of what I consider to be priorities, in
>> some rough
>>>>> categories.  As you see, there's a *LOT* that falls under the WG
>>>>> charter, and there is no way we could work on even 1/3 or 1/4 of
>>>>> these at the same time.  So, there must be some priorization.
>>>>>
>>>>> I welcome comments especially if you think I've badly
>> misprioritized
>>>>> document/work that relates to the v6ops charter.
>>>>>
>>>>> ======
>>>>>
>>>>> The most important work
>>>>> - finish enterprise analysis
>>>>> - finish requirement(s) for tunneling
>>>>>    * to be able to decide whether existing solution(s)
>> are sufficient
>>>>>      and if not, get started on specifying new ones
>>>>> - get started on mechanisms (somewhere else?) if needed/necessary
>>>>>
>>>>> Pretty darn important work
>>>>> - the last spin at 3GPP analysis doc, updated IMS scenario
>>>>> - better document the ISP's broadband transition scenarios
>>>>>    * draft-asadullah-v6ops-bb-deployment-scenarios-01
>>>>> - finish draft-ietf-v6ops-mech-v2
>>>>>    * waiting for feedback from the IESG telechat..
>>>>> - adopt and finish draft-tschofenig-v6ops-secure-tunnels-02.txt
>>>>>    * IESG requirement for draft-ietf-v6ops-mech-v2
>>>>> - figure what to do about the NAT-PT deprecation/analysis
>>>>>   *  draft-aoun-v6ops-natpt-deprecate
>>>>> - (techno-political) document for v4 NAT users
>>>>>   * draft-vandevelde-v6ops-nap
>>>>> - IPv6-on-by-default work, fixes need to be integrated in
>> the IETF work
>>>>>   * draft-ietf-v6ops-onlinkassumption
>>>>>   * draft-ietf-v6ops-v6onbydefault
>>>>>   * etc.
>>>>>
>>>>> Important work
>>>>> - draft-ietf-v6ops-renumbering-procedure
>>>>>   * needs revision to address IESG comments
>>>>> - draft-palet-v6ops-tun-auto-disc
>>>>> - draft-chown-v6ops-vlan-usage
>>>>> - figuring out how to deal with Mobile IP transition issues
>>>>> - security overview of IPv6
>>>>>    * draft-savola-v6ops-security-overview
>>>>>
>>>>> Useful work
>>>>> - revising 6to4 spec to be clearer, etc.
>>>>> - draft-palet-v6ops-solution-tun-auto-disc
>>>>> - draft-chown-v6ops-renumber-thinkabout-00
>>>>> - draft-chown-v6ops-port-scanning-implications
>>>>>
>>>>> Difficult to say whether it has gained sufficient
>> momentum, and/or
>>>>> whether this is the right place to do this
>>>>> - draft-palet-v6ops-auto-trans
>>>>> - draft-palet-v6ops-ipv6security
>>>>> - draft-vives-v6ops-ipv6-security-ps
>>>>> - draft-kondo-quarantine-overview-01.txt
>>>>>
>>>>> Not sure whether it should be published as RFC, or is sufficiently
>>>>> relevant
>>>>> - draft-chown-v6ops-campus-transition
>>>>> - draft-morelli-v6ops-ipv6-ix
>>>>>
--1589707168-877944872-1099673674=:18349--



From owner-v6ops@ops.ietf.org  Fri Nov  5 12:01:08 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28818
	for <v6ops-archive@lists.ietf.org>; Fri, 5 Nov 2004 12:01:08 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CQ7S5-000MF2-5w
	for v6ops-data@psg.com; Fri, 05 Nov 2004 17:00:41 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CQ7S3-000MET-NC
	for v6ops@ops.ietf.org; Fri, 05 Nov 2004 17:00:40 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id iA5H0c918669
	for <v6ops@ops.ietf.org>; Fri, 5 Nov 2004 19:00:38 +0200
Date: Fri, 5 Nov 2004 19:00:38 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: v6ops@ops.ietf.org
Subject: BOUNCE v6ops@ops.ietf.org:    Non-member submission from
 [=?iso-8859-1?Q?R=E9mi_Despr=E9s?= <remi.despres@rd-iptech.com>]    (fwd)
Message-ID: <Pine.LNX.4.61.0411051858440.18349@netcore.fi>
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="1589707168-1677018144-1099673939=:18349"
Content-ID: <Pine.LNX.4.61.0411051859270.18349@netcore.fi>
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--1589707168-1677018144-1099673939=:18349
Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1; FORMAT=flowed
Content-ID: <Pine.LNX.4.61.0411051859271.18349@netcore.fi>
Content-Transfer-Encoding: 8BIT

Approved: drops
>From remi.despres@rd-iptech.com Fri Nov 05 12:34:16 2004
Received: from [193.252.22.29] (helo=mwinf0203.wanadoo.fr)
 	by psg.com with esmtp (Exim 4.41 (FreeBSD))
 	id 1CQ3IF-0008lF-UX
 	for v6ops@ops.ietf.org; Fri, 05 Nov 2004 12:34:16 +0000
Received: from me-wanadoo.net (localhost [127.0.0.1])
 	by mwinf0203.wanadoo.fr (SMTP Server) with SMTP
 	id BF32F100008F; Fri,  5 Nov 2004 13:34:14 +0100 (CET)
Received: from Rmi (APuteaux-105-1-3-243.w80-11.abo.wanadoo.fr [80.11.85.243])
 	by mwinf0203.wanadoo.fr (SMTP Server) with SMTP
 	id 24556100008E; Fri,  5 Nov 2004 13:34:14 +0100 (CET)
Message-ID: <006e01c4c333$c29ec530$0200a8c0@Rmi>
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= <remi.despres@rd-iptech.com>
To: <jordi.palet@consulintel.es>, <v6ops@ops.ietf.org>
References: <BDB07704.4DFB1%jordi.palet@consulintel.es>
Subject: Re: A personal take on WG's priorities..
Date: Fri, 5 Nov 2004 13:34:12 +0100
MIME-Version: 1.0
Content-Type: text/plain;
 	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Level:
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham
 	version=2.64

Jordi, Jim, Pekka,

As explained in http://perso.wanadoo.fr/remi.despres/4to6.htm there seems to
be important missing pieces for a number of desirable transition
configurations, with possible solutions to satisfy these needs.
IMHO, some group work somehere on the subject should  be possible.

Rémi

----- Original Message -----
From: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>
To: <v6ops@ops.ietf.org>
Sent: Friday, November 05, 2004 12:17 AM
Subject: Re: A personal take on WG's priorities..


Jim,

My view is that we should only work in new transition mechanism if there is
something _really_ not covered already, but we also should work on those "de
facto" mechanism to get standardized if it make sense.

Regards,
Jordi

> De: "Bound, Jim" <jim.bound@hp.com>
> Responder a: owner-v6ops@ops.ietf.org
> Fecha: Thu, 4 Nov 2004 13:10:57 -0500
> Para: "Brian E Carpenter" <brc@zurich.ibm.com>,
<jordi.palet@consulintel.es>
> CC: <v6ops@ops.ietf.org>
> Asunto: RE: A personal take on WG's priorities..
>
> But I don't agree we should not work on new emerging transition mechanisms
> that in fact are being deployed as we talk here.
> /jim
>>>> Pekka Savola wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Based on the discussion on what the WG should be doing, I
>> cooked up
>>>>> my
>>>>> **personal** list of what I consider to be priorities, in
>> some rough
>>>>> categories.  As you see, there's a *LOT* that falls under the WG
>>>>> charter, and there is no way we could work on even 1/3 or 1/4 of
>>>>> these at the same time.  So, there must be some priorization.
>>>>>
>>>>> I welcome comments especially if you think I've badly
>> misprioritized
>>>>> document/work that relates to the v6ops charter.
>>>>>
>>>>> ======
>>>>>
>>>>> The most important work
>>>>> - finish enterprise analysis
>>>>> - finish requirement(s) for tunneling
>>>>>    * to be able to decide whether existing solution(s)
>> are sufficient
>>>>>      and if not, get started on specifying new ones
>>>>> - get started on mechanisms (somewhere else?) if needed/necessary
>>>>>
>>>>> Pretty darn important work
>>>>> - the last spin at 3GPP analysis doc, updated IMS scenario
>>>>> - better document the ISP's broadband transition scenarios
>>>>>    * draft-asadullah-v6ops-bb-deployment-scenarios-01
>>>>> - finish draft-ietf-v6ops-mech-v2
>>>>>    * waiting for feedback from the IESG telechat..
>>>>> - adopt and finish draft-tschofenig-v6ops-secure-tunnels-02.txt
>>>>>    * IESG requirement for draft-ietf-v6ops-mech-v2
>>>>> - figure what to do about the NAT-PT deprecation/analysis
>>>>>   *  draft-aoun-v6ops-natpt-deprecate
>>>>> - (techno-political) document for v4 NAT users
>>>>>   * draft-vandevelde-v6ops-nap
>>>>> - IPv6-on-by-default work, fixes need to be integrated in
>> the IETF work
>>>>>   * draft-ietf-v6ops-onlinkassumption
>>>>>   * draft-ietf-v6ops-v6onbydefault
>>>>>   * etc.
>>>>>
>>>>> Important work
>>>>> - draft-ietf-v6ops-renumbering-procedure
>>>>>   * needs revision to address IESG comments
>>>>> - draft-palet-v6ops-tun-auto-disc
>>>>> - draft-chown-v6ops-vlan-usage
>>>>> - figuring out how to deal with Mobile IP transition issues
>>>>> - security overview of IPv6
>>>>>    * draft-savola-v6ops-security-overview
>>>>>
>>>>> Useful work
>>>>> - revising 6to4 spec to be clearer, etc.
>>>>> - draft-palet-v6ops-solution-tun-auto-disc
>>>>> - draft-chown-v6ops-renumber-thinkabout-00
>>>>> - draft-chown-v6ops-port-scanning-implications
>>>>>
>>>>> Difficult to say whether it has gained sufficient
>> momentum, and/or
>>>>> whether this is the right place to do this
>>>>> - draft-palet-v6ops-auto-trans
>>>>> - draft-palet-v6ops-ipv6security
>>>>> - draft-vives-v6ops-ipv6-security-ps
>>>>> - draft-kondo-quarantine-overview-01.txt
>>>>>
>>>>> Not sure whether it should be published as RFC, or is sufficiently
>>>>> relevant
>>>>> - draft-chown-v6ops-campus-transition
>>>>> - draft-morelli-v6ops-ipv6-ix
>>>>>
--1589707168-1677018144-1099673939=:18349--



From owner-v6ops@ops.ietf.org  Fri Nov  5 12:08:42 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29320
	for <v6ops-archive@lists.ietf.org>; Fri, 5 Nov 2004 12:08:42 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CQ7ZC-000NgW-QJ
	for v6ops-data@psg.com; Fri, 05 Nov 2004 17:08:02 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CQ7Z8-000Nfq-5z
	for v6ops@ops.ietf.org; Fri, 05 Nov 2004 17:07:58 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id iA5H7u018909
	for <v6ops@ops.ietf.org>; Fri, 5 Nov 2004 19:07:56 +0200
Date: Fri, 5 Nov 2004 19:07:56 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: v6ops@ops.ietf.org
Subject: BOUNCE v6ops@ops.ietf.org:    Non-member submission from
 [=?iso-8859-1?Q?R=E9mi_Despr=E9s?= <remi.despres@rd-iptech.com>]    (fwd)
Message-ID: <Pine.LNX.4.61.0411051907120.18349@netcore.fi>
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="1589707168-2011425102-1099674476=:18349"
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--1589707168-2011425102-1099674476=:18349
Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8BIT

Approved: drops
>From remi.despres@rd-iptech.com Fri Nov 05 12:34:16 2004
Received: from [193.252.22.29] (helo=mwinf0203.wanadoo.fr)
 	by psg.com with esmtp (Exim 4.41 (FreeBSD))
 	id 1CQ3IF-0008lF-UX
 	for v6ops@ops.ietf.org; Fri, 05 Nov 2004 12:34:16 +0000
Received: from me-wanadoo.net (localhost [127.0.0.1])
 	by mwinf0203.wanadoo.fr (SMTP Server) with SMTP
 	id BF32F100008F; Fri,  5 Nov 2004 13:34:14 +0100 (CET)
Received: from Rmi (APuteaux-105-1-3-243.w80-11.abo.wanadoo.fr [80.11.85.243])
 	by mwinf0203.wanadoo.fr (SMTP Server) with SMTP
 	id 24556100008E; Fri,  5 Nov 2004 13:34:14 +0100 (CET)
Message-ID: <006e01c4c333$c29ec530$0200a8c0@Rmi>
From: Remi_Despres <remi.despres@rd-iptech.com>
To: <jordi.palet@consulintel.es>, <v6ops@ops.ietf.org>
References: <BDB07704.4DFB1%jordi.palet@consulintel.es>
Subject: Re: A personal take on WG's priorities..
Date: Fri, 5 Nov 2004 13:34:12 +0100
MIME-Version: 1.0
Content-Type: text/plain;
 	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Level:
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham
 	version=2.64

Jordi, Jim, Pekka,

As explained in http://perso.wanadoo.fr/remi.despres/4to6.htm there seems to
be important missing pieces for a number of desirable transition
configurations, with possible solutions to satisfy these needs.
IMHO, some group work somehere on the subject should  be possible.

Rémi

----- Original Message -----
From: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>
To: <v6ops@ops.ietf.org>
Sent: Friday, November 05, 2004 12:17 AM
Subject: Re: A personal take on WG's priorities..


Jim,

My view is that we should only work in new transition mechanism if there is
something _really_ not covered already, but we also should work on those "de
facto" mechanism to get standardized if it make sense.

Regards,
Jordi

> De: "Bound, Jim" <jim.bound@hp.com>
> Responder a: owner-v6ops@ops.ietf.org
> Fecha: Thu, 4 Nov 2004 13:10:57 -0500
> Para: "Brian E Carpenter" <brc@zurich.ibm.com>,
<jordi.palet@consulintel.es>
> CC: <v6ops@ops.ietf.org>
> Asunto: RE: A personal take on WG's priorities..
>
> But I don't agree we should not work on new emerging transition mechanisms
> that in fact are being deployed as we talk here.
> /jim
>>>> Pekka Savola wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Based on the discussion on what the WG should be doing, I
>> cooked up
>>>>> my
>>>>> **personal** list of what I consider to be priorities, in
>> some rough
>>>>> categories.  As you see, there's a *LOT* that falls under the WG
>>>>> charter, and there is no way we could work on even 1/3 or 1/4 of
>>>>> these at the same time.  So, there must be some priorization.
>>>>>
>>>>> I welcome comments especially if you think I've badly
>> misprioritized
>>>>> document/work that relates to the v6ops charter.
>>>>>
>>>>> ======
>>>>>
>>>>> The most important work
>>>>> - finish enterprise analysis
>>>>> - finish requirement(s) for tunneling
>>>>>    * to be able to decide whether existing solution(s)
>> are sufficient
>>>>>      and if not, get started on specifying new ones
>>>>> - get started on mechanisms (somewhere else?) if needed/necessary
>>>>>
>>>>> Pretty darn important work
>>>>> - the last spin at 3GPP analysis doc, updated IMS scenario
>>>>> - better document the ISP's broadband transition scenarios
>>>>>    * draft-asadullah-v6ops-bb-deployment-scenarios-01
>>>>> - finish draft-ietf-v6ops-mech-v2
>>>>>    * waiting for feedback from the IESG telechat..
>>>>> - adopt and finish draft-tschofenig-v6ops-secure-tunnels-02.txt
>>>>>    * IESG requirement for draft-ietf-v6ops-mech-v2
>>>>> - figure what to do about the NAT-PT deprecation/analysis
>>>>>   *  draft-aoun-v6ops-natpt-deprecate
>>>>> - (techno-political) document for v4 NAT users
>>>>>   * draft-vandevelde-v6ops-nap
>>>>> - IPv6-on-by-default work, fixes need to be integrated in
>> the IETF work
>>>>>   * draft-ietf-v6ops-onlinkassumption
>>>>>   * draft-ietf-v6ops-v6onbydefault
>>>>>   * etc.
>>>>>
>>>>> Important work
>>>>> - draft-ietf-v6ops-renumbering-procedure
>>>>>   * needs revision to address IESG comments
>>>>> - draft-palet-v6ops-tun-auto-disc
>>>>> - draft-chown-v6ops-vlan-usage
>>>>> - figuring out how to deal with Mobile IP transition issues
>>>>> - security overview of IPv6
>>>>>    * draft-savola-v6ops-security-overview
>>>>>
>>>>> Useful work
>>>>> - revising 6to4 spec to be clearer, etc.
>>>>> - draft-palet-v6ops-solution-tun-auto-disc
>>>>> - draft-chown-v6ops-renumber-thinkabout-00
>>>>> - draft-chown-v6ops-port-scanning-implications
>>>>>
>>>>> Difficult to say whether it has gained sufficient
>> momentum, and/or
>>>>> whether this is the right place to do this
>>>>> - draft-palet-v6ops-auto-trans
>>>>> - draft-palet-v6ops-ipv6security
>>>>> - draft-vives-v6ops-ipv6-security-ps
>>>>> - draft-kondo-quarantine-overview-01.txt
>>>>>
>>>>> Not sure whether it should be published as RFC, or is sufficiently
>>>>> relevant
>>>>> - draft-chown-v6ops-campus-transition
>>>>> - draft-morelli-v6ops-ipv6-ix
>>>>>

--1589707168-2011425102-1099674476=:18349--



From owner-v6ops@ops.ietf.org  Fri Nov  5 12:14:48 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29642
	for <v6ops-archive@lists.ietf.org>; Fri, 5 Nov 2004 12:14:47 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CQ7fL-000OkE-Ag
	for v6ops-data@psg.com; Fri, 05 Nov 2004 17:14:23 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CQ7fC-000Oj5-5b
	for v6ops@ops.ietf.org; Fri, 05 Nov 2004 17:14:14 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id iA5HEDO19134
	for <v6ops@ops.ietf.org>; Fri, 5 Nov 2004 19:14:13 +0200
Date: Fri, 5 Nov 2004 19:14:13 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: v6ops@ops.ietf.org
Subject: Re: BOUNCE v6ops@ops.ietf.org:    Non-member submission from
 [=?iso-8859-1?Q?R=E9mi_Despr=E9s?= <remi.despres@rd-iptech.com>]    (fwd)
In-Reply-To: <Pine.LNX.4.61.0411051907120.18349@netcore.fi>
Message-ID: <Pine.LNX.4.61.0411051913250.18349@netcore.fi>
References: <Pine.LNX.4.61.0411051907120.18349@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

On Fri, 5 Nov 2004, Pekka Savola wrote:

Sorry about the mess -- it appears it wasn't my fat fingers, but 
something (probably) broken at the server end during the last couple 
of days.  I'll try to get this fixed ASAP.

-- 
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 owner-v6ops@ops.ietf.org  Fri Nov  5 12:28:12 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00676
	for <v6ops-archive@lists.ietf.org>; Fri, 5 Nov 2004 12:28:12 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CQ7sB-0000k4-0D
	for v6ops-data@psg.com; Fri, 05 Nov 2004 17:27:39 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CQ7s0-0000j8-1Q
	for v6ops@ops.ietf.org; Fri, 05 Nov 2004 17:27:28 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id iA5HROM19545;
	Fri, 5 Nov 2004 19:27:24 +0200
Date: Fri, 5 Nov 2004 19:27:24 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
cc: v6ops@ops.ietf.org
Subject: Re: other comments on draft-nielsen-v6ops-3GPP-zeroconf-goals-00.
 txt
In-Reply-To: <BDB16935.4E3CE%jordi.palet@consulintel.es>
Message-ID: <Pine.LNX.4.61.0411051901430.18349@netcore.fi>
References: <BDB16935.4E3CE%jordi.palet@consulintel.es>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

Hi,

On Fri, 5 Nov 2004, JORDI PALET MARTINEZ wrote:
> You mean including in the next version of 
> draft-palet-v6ops-tun-auto-disc something specific to 3GPP 
> considerations ?

Not really, though if it's believed that 3GPP's case differs 
significantly in scenarios in section 2, more text could be added 
there.  I'd think the 3GPP should be already rather well covered there 
and in the other documents.

I was referring that the 3GPP goals document might want to expand a 
bit on its endpoint discovery requirements.

See below..

> No problem in doing that. Will try to work on this next week, but can't
> promise being so fast this time !

No big hurry with this.

> Also, we have already some text regarding NAPTR, but we can expand if
> required. Any specific suggestion or text that someone want to propose ?

This was more what I was after with respect to 'tun-auto-disc' 
solution.  If Alain thought the current reference to 'tun-auto-disc' 
was not sufficient, that seemed to hint that the attributes of the 
solution might not have been sufficiently discussed in tun-auto-disc.

As to the attributes of the reverse lookup schemes, one might say a 
few good / bad sides, like:
  - bad side is that requires a lot of records
  - also requires some kind of special population of the private 
address space etc. if used between the user and the customer, pretty 
ugly.
  - increases the number of required lookups
  - on the other side, allows more flexible, IP-specific configuration

Also, two particular more generic issues, AFAIR, which could be 
discussed a bit more might be:

  - the "granularity" of the discovery process, i.e., how precisely and 
easily should you be able to modify the results of the lookup, e.g., 
tune that hosts A..B within a single administrative domain should 
discover X, hosts B..C should discover Y, etc. (for example, when 
using DNS, one way to achieve this would be split-faced DNS, or 
looking up stuff from the reverses like Alain proposes).

  - the manageability domain of the host.  It can be argued that IP 
addresses are often more "local" than host names.  A search path could 
include even all of the enterprise, all over the world, while 
customizing the lookup results (above) based on the IP address might 
go closer to the administrative domains.

It could also be argued that this may not be all that severe a problem 
here, if DNS is combined with anycast (provided that split DNS is not 
used).  Even if node X gets the same IP address everywhere by looking 
up x_srv.example.com, x_srv.example.com can be anycasted, set up 
everywhere using the same IP address.

But as said, there are certainly a lot of arguments for or against 
about this kind of customization.

-- 
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 owner-v6ops@ops.ietf.org  Fri Nov  5 12:30:17 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00815
	for <v6ops-archive@lists.ietf.org>; Fri, 5 Nov 2004 12:30:17 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CQ7uQ-00013e-2v
	for v6ops-data@psg.com; Fri, 05 Nov 2004 17:29:58 +0000
Received: from [192.18.98.36] (helo=brmea-mail-4.sun.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CQ7uH-00012i-6k
	for v6ops@ops.ietf.org; Fri, 05 Nov 2004 17:29:49 +0000
Received: from esunmail ([129.147.156.34])
	by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id iA5HTmNH011006
	for <v6ops@ops.ietf.org>; Fri, 5 Nov 2004 10:29:48 -0700 (MST)
Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM
 (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTP id <0I6P0095PV9NHH@edgemail1.Central.Sun.COM> for
 v6ops@ops.ietf.org; Fri, 05 Nov 2004 10:29:48 -0700 (MST)
Received: from [192.168.1.102] ([66.93.39.75])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I6P00556V9MHF@mail.sun.net> for v6ops@ops.ietf.org; Fri,
 05 Nov 2004 10:29:47 -0700 (MST)
Date: Fri, 05 Nov 2004 09:31:27 -0800
From: Alain Durand <Alain.Durand@Sun.COM>
Subject: Re: other comments on draft-nielsen-v6ops-3GPP-zeroconf-goals-00. txt
In-reply-to: <Pine.LNX.4.61.0411051531090.13462@netcore.fi>
To: Pekka Savola <pekkas@netcore.fi>
Cc: "Karen E. Nielsen (AH/LMD)" <karen.e.nielsen@ericsson.com>,
        "'''IPv6 Operations ' ' '" <v6ops@ops.ietf.org>
Message-id: <418BB8EF.4080906@sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20040906
References: 
 <C26BB8276599A44B85D52F9CE41035E1050B9805@esealnt944.al.sw.ericsson.se>
 <Pine.LNX.4.61.0411051531090.13462@netcore.fi>
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7BIT

Pekka Savola wrote:

> One comment on a comment,
>
> On Fri, 5 Nov 2004, Karen E. Nielsen (AH/LMD) wrote:
>
>>> Tunnel end-point discovery
>>> -------------------------------------
>>> This document should also reference
>>> http://www.ietf.org/internet-drafts/draft-yamamoto-naptr-service-
>>> discovery-00.txt
>>>
>>
>> Yes, now it should. Thanks.
>>
>> Let me and the other authors think about how it should be put 
>> exactly, I have a small concern with this in the 3gpp environment due 
>> to RT delays (more or that to come).
>
>
> Let me disagree here, rather strongly.
>
> The requirements document like this should not point at various 
> solutions documents.  In the case of tunnel endpoint discovery, we 
> have a good document (draft-palet-v6ops-tun-auto-disc-00.txt) -- which 
> could include more discussion relating to draft-yamamoto-, but there 
> is no need to refer to that *HERE*.

We might be in violent agreement. My point is that either the 
requirement specs reference
all possible solutions or none and stick to requirements.
Referencing only one potential solution is wrong.
That said, I agree that all the tunnel end point discovery solutions 
should be merged.

    - Alain.




From owner-v6ops@ops.ietf.org  Fri Nov  5 13:02:58 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03538
	for <v6ops-archive@lists.ietf.org>; Fri, 5 Nov 2004 13:02:58 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CQ8P2-0006Nf-I2
	for v6ops-data@psg.com; Fri, 05 Nov 2004 18:01:36 +0000
Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CQ8P0-0006N8-UP
	for v6ops@ops.ietf.org; Fri, 05 Nov 2004 18:01:35 +0000
Received: from esunmail ([129.147.156.34])
	by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id iA5I1Yui022700
	for <v6ops@ops.ietf.org>; Fri, 5 Nov 2004 11:01:34 -0700 (MST)
Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM
 (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTP id <0I6P00C2GWQL3Q@edgemail1.Central.Sun.COM> for
 v6ops@ops.ietf.org; Fri, 05 Nov 2004 11:01:33 -0700 (MST)
Received: from [192.168.1.102] ([66.93.39.75])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I6P0042FWQK1J@mail.sun.net> for v6ops@ops.ietf.org; Fri,
 05 Nov 2004 11:01:33 -0700 (MST)
Date: Fri, 05 Nov 2004 10:03:12 -0800
From: Alain Durand <Alain.Durand@Sun.COM>
Subject: Re: other comments on draft-nielsen-v6ops-3GPP-zeroconf-goals-00. txt
In-reply-to: <BDB16935.4E3CE%jordi.palet@consulintel.es>
To: jordi.palet@consulintel.es
Cc: v6ops@ops.ietf.org
Message-id: <418BC060.2030702@sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20040906
References: <BDB16935.4E3CE%jordi.palet@consulintel.es>
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7BIT

JORDI PALET MARTINEZ wrote:

>Hi Pekka,
>
>You mean including in the next version of draft-palet-v6ops-tun-auto-disc
>something specific to 3GPP considerations ?
>
>No problem in doing that. Will try to work on this next week, but can't
>promise being so fast this time !
>
>Also, we have already some text regarding NAPTR, but we can expand if
>required. Any specific suggestion or text that someone want to propose ?
>  
>
Jordi,

I could send you some text summarizing the NATPR solution,
but this is not what is needed the most at this point in time.

IMHO, we need to understand what are the real requirements
of the different customers (read assisted tunnels, zero conf & 3GPP, 
potentialy others)
and compare the different solutions with those requirements.

I believe that the 3 customers have the same fundamental need,
i.e. a DHCP based solution won't work (difficult to deploy),
there is a desire to match the underlying topology as well as possible,
and the number of round-trip should be minimize, especially in the 3GPP 
case.

So, I agree with your conclusion in draft-palet-v6ops-tun-auto-disc-02.txt
that a DNS based solution is the right approach. The point to discuss
is should this be done in the forward or reverse DNS tree? I tend to preffer
doing it in the reverse tree because it matches the physical topology.
The only argument so far I've heard against it is the number of packet 
exchange necesssary,
(2 instead of 1) however there is a solution to that by padding data in 
the additional section,
same as what is done for CNAME.

I hope we could find time in D.C. to discuss this further and have the 
wg come
with a single recommended solution.

    - Alain.



From owner-v6ops@ops.ietf.org  Fri Nov  5 13:29:49 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05305
	for <v6ops-archive@lists.ietf.org>; Fri, 5 Nov 2004 13:29:49 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CQ8pw-000AuE-JF
	for v6ops-data@psg.com; Fri, 05 Nov 2004 18:29:24 +0000
Received: from [192.18.98.36] (helo=brmea-mail-4.sun.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CQ8pv-000Atl-IU
	for v6ops@ops.ietf.org; Fri, 05 Nov 2004 18:29:23 +0000
Received: from esunmail ([129.147.156.34])
	by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id iA5ITNNH019251
	for <v6ops@ops.ietf.org>; Fri, 5 Nov 2004 11:29:23 -0700 (MST)
Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM
 (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTP id <0I6P0097GY0YHH@edgemail1.Central.Sun.COM> for
 v6ops@ops.ietf.org; Fri, 05 Nov 2004 11:29:23 -0700 (MST)
Received: from [192.168.1.102] ([66.93.39.75])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I6P0048SY0X1E@mail.sun.net> for v6ops@ops.ietf.org; Fri,
 05 Nov 2004 11:29:22 -0700 (MST)
Date: Fri, 05 Nov 2004 10:31:02 -0800
From: Alain Durand <Alain.Durand@Sun.COM>
Subject: Re: other comments on draft-nielsen-v6ops-3GPP-zeroconf-goals-00. txt
In-reply-to: <Pine.LNX.4.61.0411051901430.18349@netcore.fi>
To: Pekka Savola <pekkas@netcore.fi>
Cc: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>, v6ops@ops.ietf.org
Message-id: <418BC6E6.5010906@sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20040906
References: <BDB16935.4E3CE%jordi.palet@consulintel.es>
 <Pine.LNX.4.61.0411051901430.18349@netcore.fi>
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7BIT

Pekka Savola wrote:

>
>
> As to the attributes of the reverse lookup schemes, one might say a 
> few good / bad sides, like:
>   - bad side is that requires a lot of records

    not an issue as they can be generated with script.

>   - also requires some kind of special population of the private 
> address space etc. if used between the user and the customer, pretty 
> ugly.


This is an area that need invetigation, I agree.

>   - increases the number of required lookups

Not necessarily. Think CNAME and additional section.

>   - on the other side, allows more flexible, IP-specific configuration
>
> Also, two particular more generic issues, AFAIR, which could be 
> discussed a bit more might be:
>
>   - the "granularity" of the discovery process, i.e., how precisely 
> and easily should you be able to modify the results of the lookup, 
> e.g., tune that hosts A..B within a single administrative domain 
> should discover X, hosts B..C should discover Y, etc. (for example, 
> when using DNS, one way to achieve this would be split-faced DNS, or 
> looking up stuff from the reverses like Alain proposes).

In practice, I think this is an important operational issue.

>
>   - the manageability domain of the host.  It can be argued that IP 
> addresses are often more "local" than host names.  A search path could 
> include even all of the enterprise, all over the world, while 
> customizing the lookup results (above) based on the IP address might 
> go closer to the administrative domains.


Search path are just plain wrong. As I explained several times, 
internally at Sun, we have domains
that span the planet and many hosts are`configured with several domains 
in their search path.

>
>
> It could also be argued that this may not be all that severe a problem 
> here, if DNS is combined with anycast (provided that split DNS is not 
> used).  Even if node X gets the same IP address everywhere by looking 
> up x_srv.example.com, x_srv.example.com can be anycasted, set up 
> everywhere using the same IP address.

That makes the asumption that we know how to limit the propagation of 
anycast routes
within large domains. This is certainly doable, but the associated 
complexity is large.

    - Alain.



From owner-v6ops@ops.ietf.org  Fri Nov  5 13:30:32 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05374
	for <v6ops-archive@lists.ietf.org>; Fri, 5 Nov 2004 13:30:32 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CQ8qt-000B3F-VM
	for v6ops-data@psg.com; Fri, 05 Nov 2004 18:30:23 +0000
Received: from [213.172.48.142] (helo=consulintel.es)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CQ8qs-000B2s-P1
	for v6ops@ops.ietf.org; Fri, 05 Nov 2004 18:30:23 +0000
Received: from [10.10.10.102] ([217.126.187.160])
	by consulintel.es (consulintel.es [127.0.0.1])
	(MDaemon.PRO.v7.2.0.R)
	with ESMTP id md50000561316.msg
	for <v6ops@ops.ietf.org>; Fri, 05 Nov 2004 19:35:51 +0100
User-Agent: Microsoft-Entourage/10.1.4.030702.0
Date: Fri, 05 Nov 2004 19:30:15 +0100
Subject: Re: other comments on draft-nielsen-v6ops-3GPP-zeroconf-goals-00.
	txt
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: <v6ops@ops.ietf.org>
Message-ID: <BDB18547.4E438%jordi.palet@consulintel.es>
In-Reply-To: <418BB8EF.4080906@sun.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Spam-Processed: consulintel.es, Fri, 05 Nov 2004 19:35:51 +0100
	(not processed: message from valid local sender)
X-MDRemoteIP: 217.126.187.160
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ops.ietf.org
Reply-To: jordi.palet@consulintel.es
X-MDAV-Processed: consulintel.es, Fri, 05 Nov 2004 19:35:53 +0100
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Alain,

Our document is doing an analysis of all possible solutions. Our suggested
solution is a different document.

Our analysis document already includes NAPTR description, but we may need to
expand to reverse, which will be the right way to proceed with an analysis
document to be as much comprehensive as possible.

Regards,
Jordi


> De: Alain Durand <Alain.Durand@Sun.COM>
> Responder a: owner-v6ops@ops.ietf.org
> Fecha: Fri, 05 Nov 2004 09:31:27 -0800
> Para: Pekka Savola <pekkas@netcore.fi>
> CC: "Karen E. Nielsen (AH/LMD)" <karen.e.nielsen@ericsson.com>, "'''IPv6
> Operations ' ' '" <v6ops@ops.ietf.org>
> Asunto: Re: other comments on draft-nielsen-v6ops-3GPP-zeroconf-goals-00. txt
> 
> Pekka Savola wrote:
> 
>> One comment on a comment,
>> 
>> On Fri, 5 Nov 2004, Karen E. Nielsen (AH/LMD) wrote:
>> 
>>>> Tunnel end-point discovery
>>>> -------------------------------------
>>>> This document should also reference
>>>> http://www.ietf.org/internet-drafts/draft-yamamoto-naptr-service-
>>>> discovery-00.txt
>>>> 
>>> 
>>> Yes, now it should. Thanks.
>>> 
>>> Let me and the other authors think about how it should be put
>>> exactly, I have a small concern with this in the 3gpp environment due
>>> to RT delays (more or that to come).
>> 
>> 
>> Let me disagree here, rather strongly.
>> 
>> The requirements document like this should not point at various
>> solutions documents.  In the case of tunnel endpoint discovery, we
>> have a good document (draft-palet-v6ops-tun-auto-disc-00.txt) -- which
>> could include more discussion relating to draft-yamamoto-, but there
>> is no need to refer to that *HERE*.
> 
> We might be in violent agreement. My point is that either the
> requirement specs reference
> all possible solutions or none and stick to requirements.
> Referencing only one potential solution is wrong.
> That said, I agree that all the tunnel end point discovery solutions
> should be merged.
> 
>   - Alain.
> 
> 
> 



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






From owner-v6ops@ops.ietf.org  Fri Nov  5 13:42:52 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06259
	for <v6ops-archive@lists.ietf.org>; Fri, 5 Nov 2004 13:42:52 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CQ91j-000D3r-AD
	for v6ops-data@psg.com; Fri, 05 Nov 2004 18:41:35 +0000
Received: from [213.172.48.142] (helo=consulintel.es)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CQ91h-000D3H-V9
	for v6ops@ops.ietf.org; Fri, 05 Nov 2004 18:41:34 +0000
Received: from [10.10.10.102] ([217.126.187.160])
	by consulintel.es (consulintel.es [127.0.0.1])
	(MDaemon.PRO.v7.2.0.R)
	with ESMTP id md50000561336.msg
	for <v6ops@ops.ietf.org>; Fri, 05 Nov 2004 19:47:03 +0100
User-Agent: Microsoft-Entourage/10.1.4.030702.0
Date: Fri, 05 Nov 2004 19:41:24 +0100
Subject: Re: other comments on draft-nielsen-v6ops-3GPP-zeroconf-goals-00.
	txt
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: <v6ops@ops.ietf.org>
Message-ID: <BDB187E4.4E453%jordi.palet@consulintel.es>
In-Reply-To: <418BC060.2030702@sun.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Spam-Processed: consulintel.es, Fri, 05 Nov 2004 19:47:03 +0100
	(not processed: message from valid local sender)
X-MDRemoteIP: 217.126.187.160
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ops.ietf.org
Reply-To: jordi.palet@consulintel.es
X-MDAV-Processed: consulintel.es, Fri, 05 Nov 2004 19:47:04 +0100
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Alain,

I think is not really a summary what we need. The idea, in the analysis
document is to look at the pros and cons of every possible solution.

Pekka just did a very good job mainly with the cons for NAPTR, so I guess it
will be good if you can summarize the cons that we may be missing.

Your suggestion about how to approach the solution document seems quite good
to me. We can try to look into the different type of scenarios and see what
pros and cons has each possible solution, but I think is much easy and we
will come out to the same conclusion with the existing layout. May be I'm
wrong on this anyway.

Actually when you talked to me about your view on the reverse DNS, I was
initially very convinced, but when back in Madrid, checking pros and cons,
we come out to some of the (mainly) negative points (versus forward DNS),
which Pekka summarized already.

But agree, we should take a look again to all the options.

Regards,
Jordi


> De: Alain Durand <Alain.Durand@Sun.COM>
> Responder a: owner-v6ops@ops.ietf.org
> Fecha: Fri, 05 Nov 2004 10:03:12 -0800
> Para: jordi.palet@consulintel.es
> CC: v6ops@ops.ietf.org
> Asunto: Re: other comments on draft-nielsen-v6ops-3GPP-zeroconf-goals-00. txt
> 
> JORDI PALET MARTINEZ wrote:
> 
>> Hi Pekka,
>> 
>> You mean including in the next version of draft-palet-v6ops-tun-auto-disc
>> something specific to 3GPP considerations ?
>> 
>> No problem in doing that. Will try to work on this next week, but can't
>> promise being so fast this time !
>> 
>> Also, we have already some text regarding NAPTR, but we can expand if
>> required. Any specific suggestion or text that someone want to propose ?
>>  
>> 
> Jordi,
> 
> I could send you some text summarizing the NATPR solution,
> but this is not what is needed the most at this point in time.
> 
> IMHO, we need to understand what are the real requirements
> of the different customers (read assisted tunnels, zero conf & 3GPP,
> potentialy others)
> and compare the different solutions with those requirements.
> 
> I believe that the 3 customers have the same fundamental need,
> i.e. a DHCP based solution won't work (difficult to deploy),
> there is a desire to match the underlying topology as well as possible,
> and the number of round-trip should be minimize, especially in the 3GPP
> case.
> 
> So, I agree with your conclusion in draft-palet-v6ops-tun-auto-disc-02.txt
> that a DNS based solution is the right approach. The point to discuss
> is should this be done in the forward or reverse DNS tree? I tend to preffer
> doing it in the reverse tree because it matches the physical topology.
> The only argument so far I've heard against it is the number of packet
> exchange necesssary,
> (2 instead of 1) however there is a solution to that by padding data in
> the additional section,
> same as what is done for CNAME.
> 
> I hope we could find time in D.C. to discuss this further and have the
> wg come
> with a single recommended solution.
> 
>   - Alain.
> 
> 



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






From owner-v6ops@ops.ietf.org  Fri Nov  5 13:42:59 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06280
	for <v6ops-archive@lists.ietf.org>; Fri, 5 Nov 2004 13:42:58 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CQ930-000DEV-PW
	for v6ops-data@psg.com; Fri, 05 Nov 2004 18:42:54 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CQ92z-000DDs-1I
	for v6ops@ops.ietf.org; Fri, 05 Nov 2004 18:42:53 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id iA5IgpV21497
	for <v6ops@ops.ietf.org>; Fri, 5 Nov 2004 20:42:51 +0200
Date: Fri, 5 Nov 2004 20:42:51 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: v6ops@ops.ietf.org
Subject: BOUNCE v6ops@ops.ietf.org:
Message-ID: <Pine.LNX.4.61.0411052042310.20716@netcore.fi>
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="1589707168-266803405-1099680171=:20716"
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--1589707168-266803405-1099680171=:20716
Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8BIT

Approved: argh
>From remi.despres@rd-iptech.com Fri Nov 05 12:34:16 2004
Received: from [193.252.22.29] (helo=mwinf0203.wanadoo.fr)
 	by psg.com with esmtp (Exim 4.41 (FreeBSD))
 	id 1CQ3IF-0008lF-UX
 	for v6ops@ops.ietf.org; Fri, 05 Nov 2004 12:34:16 +0000
Received: from me-wanadoo.net (localhost [127.0.0.1])
 	by mwinf0203.wanadoo.fr (SMTP Server) with SMTP
 	id BF32F100008F; Fri,  5 Nov 2004 13:34:14 +0100 (CET)
Received: from Rmi (APuteaux-105-1-3-243.w80-11.abo.wanadoo.fr [80.11.85.243])
 	by mwinf0203.wanadoo.fr (SMTP Server) with SMTP
 	id 24556100008E; Fri,  5 Nov 2004 13:34:14 +0100 (CET)
Message-ID: <006e01c4c333$c29ec530$0200a8c0@Rmi>
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= <remi.despres@rd-iptech.com>
To: <jordi.palet@consulintel.es>, <v6ops@ops.ietf.org>
References: <BDB07704.4DFB1%jordi.palet@consulintel.es>
Subject: Re: A personal take on WG's priorities..
Date: Fri, 5 Nov 2004 13:34:12 +0100
MIME-Version: 1.0
Content-Type: text/plain;
 	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Level:
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham
 	version=2.64

Jordi, Jim, Pekka,

As explained in http://perso.wanadoo.fr/remi.despres/4to6.htm there seems to
be important missing pieces for a number of desirable transition
configurations, with possible solutions to satisfy these needs.
IMHO, some group work somehere on the subject should  be possible.

Rémi

----- Original Message -----
From: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>
To: <v6ops@ops.ietf.org>
Sent: Friday, November 05, 2004 12:17 AM
Subject: Re: A personal take on WG's priorities..


Jim,

My view is that we should only work in new transition mechanism if there is
something _really_ not covered already, but we also should work on those "de
facto" mechanism to get standardized if it make sense.

Regards,
Jordi

> De: "Bound, Jim" <jim.bound@hp.com>
> Responder a: owner-v6ops@ops.ietf.org
> Fecha: Thu, 4 Nov 2004 13:10:57 -0500
> Para: "Brian E Carpenter" <brc@zurich.ibm.com>,
<jordi.palet@consulintel.es>
> CC: <v6ops@ops.ietf.org>
> Asunto: RE: A personal take on WG's priorities..
>
> But I don't agree we should not work on new emerging transition mechanisms
> that in fact are being deployed as we talk here.
> /jim
>>>> Pekka Savola wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Based on the discussion on what the WG should be doing, I
>> cooked up
>>>>> my
>>>>> **personal** list of what I consider to be priorities, in
>> some rough
>>>>> categories.  As you see, there's a *LOT* that falls under the WG
>>>>> charter, and there is no way we could work on even 1/3 or 1/4 of
>>>>> these at the same time.  So, there must be some priorization.
>>>>>
>>>>> I welcome comments especially if you think I've badly
>> misprioritized
>>>>> document/work that relates to the v6ops charter.
>>>>>
>>>>> ======
>>>>>
>>>>> The most important work
>>>>> - finish enterprise analysis
>>>>> - finish requirement(s) for tunneling
>>>>>    * to be able to decide whether existing solution(s)
>> are sufficient
>>>>>      and if not, get started on specifying new ones
>>>>> - get started on mechanisms (somewhere else?) if needed/necessary
>>>>>
>>>>> Pretty darn important work
>>>>> - the last spin at 3GPP analysis doc, updated IMS scenario
>>>>> - better document the ISP's broadband transition scenarios
>>>>>    * draft-asadullah-v6ops-bb-deployment-scenarios-01
>>>>> - finish draft-ietf-v6ops-mech-v2
>>>>>    * waiting for feedback from the IESG telechat..
>>>>> - adopt and finish draft-tschofenig-v6ops-secure-tunnels-02.txt
>>>>>    * IESG requirement for draft-ietf-v6ops-mech-v2
>>>>> - figure what to do about the NAT-PT deprecation/analysis
>>>>>   *  draft-aoun-v6ops-natpt-deprecate
>>>>> - (techno-political) document for v4 NAT users
>>>>>   * draft-vandevelde-v6ops-nap
>>>>> - IPv6-on-by-default work, fixes need to be integrated in
>> the IETF work
>>>>>   * draft-ietf-v6ops-onlinkassumption
>>>>>   * draft-ietf-v6ops-v6onbydefault
>>>>>   * etc.
>>>>>
>>>>> Important work
>>>>> - draft-ietf-v6ops-renumbering-procedure
>>>>>   * needs revision to address IESG comments
>>>>> - draft-palet-v6ops-tun-auto-disc
>>>>> - draft-chown-v6ops-vlan-usage
>>>>> - figuring out how to deal with Mobile IP transition issues
>>>>> - security overview of IPv6
>>>>>    * draft-savola-v6ops-security-overview
>>>>>
>>>>> Useful work
>>>>> - revising 6to4 spec to be clearer, etc.
>>>>> - draft-palet-v6ops-solution-tun-auto-disc
>>>>> - draft-chown-v6ops-renumber-thinkabout-00
>>>>> - draft-chown-v6ops-port-scanning-implications
>>>>>
>>>>> Difficult to say whether it has gained sufficient
>> momentum, and/or
>>>>> whether this is the right place to do this
>>>>> - draft-palet-v6ops-auto-trans
>>>>> - draft-palet-v6ops-ipv6security
>>>>> - draft-vives-v6ops-ipv6-security-ps
>>>>> - draft-kondo-quarantine-overview-01.txt
>>>>>
>>>>> Not sure whether it should be published as RFC, or is sufficiently
>>>>> relevant
>>>>> - draft-chown-v6ops-campus-transition
>>>>> - draft-morelli-v6ops-ipv6-ix
>>>>>

--1589707168-266803405-1099680171=:20716--



From owner-v6ops@ops.ietf.org  Fri Nov  5 13:56:03 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07328
	for <v6ops-archive@lists.ietf.org>; Fri, 5 Nov 2004 13:56:02 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CQ9FK-000F1b-TL
	for v6ops-data@psg.com; Fri, 05 Nov 2004 18:55:38 +0000
Received: from [47.164.128.120] (helo=zctfs063.nortelnetworks.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CQ9FJ-000F18-Ec
	for v6ops@ops.ietf.org; Fri, 05 Nov 2004 18:55:37 +0000
Received: from zctfc040.europe.nortel.com (zctfc040.europe.nortel.com [47.164.129.95])
	by zctfs063.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id iA5ItYh05933
	for <v6ops@ops.ietf.org>; Fri, 5 Nov 2004 19:55:34 +0100 (MET)
Received: by zctfc040.europe.nortel.com with Internet Mail Service (5.5.2653.19)
	id <TJ1HX119>; Fri, 5 Nov 2004 19:55:32 +0100
Message-ID: <8F20221FB47FD51190AD00508BCF36BA0D4581FC@znsgy0k3.europe.nortel.com>
From: "Elwyn Davies" <elwynd@nortelnetworks.com>
To: "'v6ops@ops.ietf.org'" <v6ops@ops.ietf.org>
Subject: NAT-PT: To deprecate or not to deprecate: the question for next w
	eek's v6ops discussion
Date: Fri, 5 Nov 2004 19:55:33 +0100 
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

This email summarises the discussions that have taken place on the list
since the publication of  draft-aoun-v6ops-natpt-deprecate-00 and is
intended to servce as a basis for the debate at IETF-61.  I intend to
quickly reiterate these points (as modified by mailing list input between
now and then) at the meeting before we discuss how to proceed.

1. Document content: The issues with NA(P)T-PT:
- The general view appeared to be that the issues were pretty much complete
and accurate.  I have some detailed comments from Tony Hain but
unfortunately these relate to a pre-publication version of the draft and I
need to go back over the points with him to determine which of them are
still valid, as I think most of them had already been addressed.
- There was some discussion over whether the issues which NAT-PT and NAT
share should be duplicated or indeed be called out at all in this document.
	o Part of the point is that if we can live with these points in
respect of NAT,
        these are not necessarily reasons to deprecate NAT-PT.  NAT solves
an ongoing
        problem in IPv4 whereas NAT-PT is intended to be a transition aid.
On 
        the one hand we may feel it is easier to live with some issues if
the mechanism
        is not with us for ever, but on the other should we use a mechanism
that has 
        all these issues at all?
      o Also these issues will apply to *any* translation mechanism rather
than just
        the SIIT + DNS-ALG version which we the document is trying to
justify 
        deprecating
My view is that the issues should be called out in the document, but we
should make it more clear that they will apply to any translation mechanism
as well.  I don't think it is good to have to point to a lot of v4 specific
documents which cover other ground as well, particularly if we end up not
deprecating NAT-PT completely.  Views are sought.
- How to handle the connection to all the prior drafts which are (partially)
summarised in this document.  Is the current approach correct?

2. Use Cases for NAT-PT and other translation mechanisms
- A number of use cases where NAT-PT is being used (whether appropriately or
not) or is thought to be a possible solution were discussed. More input on
other cases and details of identified cases has been asked for and is still
wanted in some cases - please send in detailed info if possible.
- In some of these cases it looks as if NAT-PT is being used to solve a
problem which it was not really intended (e.g. using back-to-back NAT-PTs to
provide connection between (private) IPv4 domains across an IPv6 only
backbone). I believe that NAT-PT was intended mainly to solve the problem of
connecting an IPv4 only host/domain to an IPv6 only host/domain.  The
back-to-back NAT-PT solution seems to be better covered by a 4 in 6
tunneling solution.  Of course many of the issues called out in the draft do
not apply in this situation because only the IP header needs translating and
e2e IPsec will work because the packet is restored to its original form when
it reaches the other end.  ALG's would not be required.  I am not clear that
the standard form of the DNS-ALG proposed in 2766 applies to this use case.
- Front ending a legacy v4 only server: This is clearly a good use for a
straightforward translator, but there is little or no need for the
generalised DNS-ALG in this case and the translator would generally have to
handle a limited set of protocols and a limited set of v4 addresses defined
by the server it was front ending.  This is not an application for the full
generality of 2766 but I think we have to define a reduced version for this
case.  Whether it is still called NAT-PT is a moot point.
- The military case: I call it the military case but there are other related
applications which have the same problem to solve.  As I see it the scenario
involves a network of (newly created/adapted) v6 only devices that are
unable to run dual stack because of resource constraints either in the
devices or in the network connections.  These devices will, at least
transiently, need to communicate with v4 devices in other domains (which
have to remain v4 only for the same reasons of resource constraint).  The
question is whether NAT-PT is the best technology to connect the domains.
One question in my mind for the military case: The military specifically
wanted to avoid putting NAT boxes in their  networks for good cause (single
points of failure, routing constraints, security attack nexuses) - so why
should they now want NAT-PT in their networks? On the other hand there will
be at least some occasions when they have to work across domains during the
transition, but ALGs/proxies may be a better solution given that these
devices are likely to have a relatively limited set of applications.  There
are also issues with using DNS in this sort of environment - it is a 'high
availability/mobility' area and there may be worries about DNS caching
lifetimes.  More input is needed here.
- 3GPP wireless: As mentioned in the draft, it may be better to consider
using 4 in 6 or 6 in 4 tunnels to allow a single PDP context to carry both
protocols.  This may require updates to RFC3314. More work is needed to
ensure that header compression can reduce the impact on scarce bandwidth
across the air interface (an extension of ROHC should be possible to cover
tunnel headers).

Do these cases cover all the expected scenarios?  Is the analysis correct?

3. NAT-PT vs proxies
Are proxies a better solution for most/all cases?  Either proxies or NAT-PT
need to be extended to cope with new protocols in most cases.  Proxies may
be more scalable (not all in the same box) and more adaptable to user needs
(not dependent on a single vendor to do NAT-PT ALG upgrades). The most
frequently used protocols today are HTTP, POP, SMTP, FTP and SSH: proxies
are available for the first four - SSH is more problematic but is mostly a
tool for power users (who are more likely to have dual stack support) and so
SSH support may not be so important.

Way forwards:
- Tune the details
- Show real examples, if any, where translators will really give better
performance than proxies and are really vital. Make sure that backwards
compatibility is fully considered, taking into account availability and
migration of terminals from v4 to dual-stack/v6 plus the availability of
tunnel support. 
- Either:
   o Deprecate NAT-PT altogther and write other drafts with 'offspring of
NAT-PT' to
     cover the specialised use cases where a translator is useful, or
   o Turn this into a new applicability draft recommending only a very
limited set 
     of uses, and produce modifications to cater for some of the specialised
use cases.
- Produce some recommendations on proxies and look to see which other
proxies need specification (if any).
- Ensure there are suitable specification(s) for 4 in 6 tunneling
(configured, auto).
- Ensure that the various scenario drafts recommend the 'right' solution.

Regards,
Elwyn

----------------------------------------------------------------------------
------

Elwyn B Davies

        Routing and Addressing Strategy Prime & IPv6 Core Team Leader
        CTO Office, Portfolio Integration		Solutions Ready


        Nortel Networks plc			Email:
elwynd@nortelnetworks.com
        Harlow Laboratories     			ESN
6-742-5498
        London Road, Harlow,    			Direct Line
+44-1279-405498
        Essex, CM17 9NA, UK     		Fax
+44-1279-402047
        Registered Office: 			Maidenhead Office Park,
Westacott Way,
        Company No. 3937799			Maidenhead, Berkshire, SSL6
3QH
----------------------------------------------------------------------------
This message may contain information proprietary to Nortel Networks plc so
any
unauthorised disclosure, copying or distribution of its contents is strictly
prohibited.
----------------------------------------------------------------------------
"The Folly is mostly mine"
and the opinions are mine and not those of my employer.
============================================================================
======





From owner-v6ops@ops.ietf.org  Fri Nov  5 14:13:30 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08734
	for <v6ops-archive@lists.ietf.org>; Fri, 5 Nov 2004 14:13:29 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CQ9VX-000HRT-Ga
	for v6ops-data@psg.com; Fri, 05 Nov 2004 19:12:23 +0000
Received: from [193.252.22.29] (helo=mwinf0203.wanadoo.fr)
 	by psg.com with esmtp (Exim 4.41 (FreeBSD))
 	id 1CQ3IF-0008lF-UX
 	for v6ops@ops.ietf.org; Fri, 05 Nov 2004 12:34:16 +0000
Received: from me-wanadoo.net (localhost [127.0.0.1])
 	by mwinf0203.wanadoo.fr (SMTP Server) with SMTP
 	id BF32F100008F; Fri,  5 Nov 2004 13:34:14 +0100 (CET)
Received: from Rmi (APuteaux-105-1-3-243.w80-11.abo.wanadoo.fr [80.11.85.243])
 	by mwinf0203.wanadoo.fr (SMTP Server) with SMTP
 	id 24556100008E; Fri,  5 Nov 2004 13:34:14 +0100 (CET)
Message-ID: <006e01c4c333$c29ec530$0200a8c0@Rmi>
From: <remi.despres@rd-iptech.com>
To: <jordi.palet@consulintel.es>, <v6ops@ops.ietf.org>
References: <BDB07704.4DFB1%jordi.palet@consulintel.es>
Subject: Re: A personal take on WG's priorities..
Date: Fri, 5 Nov 2004 13:34:12 +0100
MIME-Version: 1.0
Content-Type: text/plain;
 	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham
 	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit

Jordi, Jim, Pekka,

As explained in http://perso.wanadoo.fr/remi.despres/4to6.htm there seems to
be important missing pieces for a number of desirable transition
configurations, with possible solutions to satisfy these needs.
IMHO, some group work somehere on the subject should  be possible.

Remi

----- Original Message ----- 
From: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>
To: <v6ops@ops.ietf.org>
Sent: Friday, November 05, 2004 12:17 AM
Subject: Re: A personal take on WG's priorities..


Jim,

My view is that we should only work in new transition mechanism if there is
something _really_ not covered already, but we also should work on those "de
facto" mechanism to get standardized if it make sense.

Regards,
Jordi

> De: "Bound, Jim" <jim.bound@hp.com>
> Responder a: owner-v6ops@ops.ietf.org
> Fecha: Thu, 4 Nov 2004 13:10:57 -0500
> Para: "Brian E Carpenter" <brc@zurich.ibm.com>,
<jordi.palet@consulintel.es>
> CC: <v6ops@ops.ietf.org>
> Asunto: RE: A personal take on WG's priorities..
>
> But I don't agree we should not work on new emerging transition mechanisms
> that in fact are being deployed as we talk here.
> /jim
>>>> Pekka Savola wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Based on the discussion on what the WG should be doing, I
>> cooked up
>>>>> my
>>>>> **personal** list of what I consider to be priorities, in
>> some rough
>>>>> categories.  As you see, there's a *LOT* that falls under the WG
>>>>> charter, and there is no way we could work on even 1/3 or 1/4 of
>>>>> these at the same time.  So, there must be some priorization.
>>>>>
>>>>> I welcome comments especially if you think I've badly
>> misprioritized
>>>>> document/work that relates to the v6ops charter.
>>>>>
>>>>> ======
>>>>>
>>>>> The most important work
>>>>> - finish enterprise analysis
>>>>> - finish requirement(s) for tunneling
>>>>>    * to be able to decide whether existing solution(s)
>> are sufficient
>>>>>      and if not, get started on specifying new ones
>>>>> - get started on mechanisms (somewhere else?) if needed/necessary
>>>>>
>>>>> Pretty darn important work
>>>>> - the last spin at 3GPP analysis doc, updated IMS scenario
>>>>> - better document the ISP's broadband transition scenarios
>>>>>    * draft-asadullah-v6ops-bb-deployment-scenarios-01
>>>>> - finish draft-ietf-v6ops-mech-v2
>>>>>    * waiting for feedback from the IESG telechat..
>>>>> - adopt and finish draft-tschofenig-v6ops-secure-tunnels-02.txt
>>>>>    * IESG requirement for draft-ietf-v6ops-mech-v2
>>>>> - figure what to do about the NAT-PT deprecation/analysis
>>>>>   *  draft-aoun-v6ops-natpt-deprecate
>>>>> - (techno-political) document for v4 NAT users
>>>>>   * draft-vandevelde-v6ops-nap
>>>>> - IPv6-on-by-default work, fixes need to be integrated in
>> the IETF work
>>>>>   * draft-ietf-v6ops-onlinkassumption
>>>>>   * draft-ietf-v6ops-v6onbydefault
>>>>>   * etc.
>>>>>
>>>>> Important work
>>>>> - draft-ietf-v6ops-renumbering-procedure
>>>>>   * needs revision to address IESG comments
>>>>> - draft-palet-v6ops-tun-auto-disc
>>>>> - draft-chown-v6ops-vlan-usage
>>>>> - figuring out how to deal with Mobile IP transition issues
>>>>> - security overview of IPv6
>>>>>    * draft-savola-v6ops-security-overview
>>>>>
>>>>> Useful work
>>>>> - revising 6to4 spec to be clearer, etc.
>>>>> - draft-palet-v6ops-solution-tun-auto-disc
>>>>> - draft-chown-v6ops-renumber-thinkabout-00
>>>>> - draft-chown-v6ops-port-scanning-implications
>>>>>
>>>>> Difficult to say whether it has gained sufficient
>> momentum, and/or
>>>>> whether this is the right place to do this
>>>>> - draft-palet-v6ops-auto-trans
>>>>> - draft-palet-v6ops-ipv6security
>>>>> - draft-vives-v6ops-ipv6-security-ps
>>>>> - draft-kondo-quarantine-overview-01.txt
>>>>>
>>>>> Not sure whether it should be published as RFC, or is sufficiently
>>>>> relevant
>>>>> - draft-chown-v6ops-campus-transition
>>>>> - draft-morelli-v6ops-ipv6-ix
>>>>>




From owner-v6ops@ops.ietf.org  Fri Nov  5 14:33:07 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09838
	for <v6ops-archive@lists.ietf.org>; Fri, 5 Nov 2004 14:33:06 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CQ9ox-000Juo-17
	for v6ops-data@psg.com; Fri, 05 Nov 2004 19:32:27 +0000
Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CQ9ov-000JuN-IV
	for v6ops@ops.ietf.org; Fri, 05 Nov 2004 19:32:25 +0000
Received: from sj-core-4.cisco.com (171.68.223.138)
  by sj-iport-5.cisco.com with ESMTP; 05 Nov 2004 11:33:19 -0800
X-BrightmailFiltered: true
Received: from ssenthil-w2k.cisco.com (dhcp-128-107-163-194.cisco.com [128.107.163.194])
	by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id iA5JWLJa016691;
	Fri, 5 Nov 2004 11:32:21 -0800 (PST)
Message-Id: <4.3.2.7.2.20041105110520.02b7b6c0@mira-sjcd-2.cisco.com>
X-Sender: ssenthil@mira-sjcd-2.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 05 Nov 2004 11:33:16 -0800
To: "Elwyn Davies" <elwynd@nortelnetworks.com>
From: Senthil Sivakumar <ssenthil@cisco.com>
Subject: Re: NAT-PT: To deprecate or not to deprecate: the question for
  next w eek's v6ops discussion
Cc: "'v6ops@ops.ietf.org'" <v6ops@ops.ietf.org>
In-Reply-To: <8F20221FB47FD51190AD00508BCF36BA0D4581FC@znsgy0k3.europe.n
 ortel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

At 07:55 PM 11/5/2004 +0100, Elwyn Davies wrote:
>This email summarises the discussions that have taken place on the list
>since the publication of  draft-aoun-v6ops-natpt-deprecate-00 and is
>intended to servce as a basis for the debate at IETF-61.  I intend to
>quickly reiterate these points (as modified by mailing list input between
>now and then) at the meeting before we discuss how to proceed.
>
>1. Document content: The issues with NA(P)T-PT:
>- The general view appeared to be that the issues were pretty much complete
>and accurate.  I have some detailed comments from Tony Hain but
>unfortunately these relate to a pre-publication version of the draft and I
>need to go back over the points with him to determine which of them are
>still valid, as I think most of them had already been addressed.
>- There was some discussion over whether the issues which NAT-PT and NAT
>share should be duplicated or indeed be called out at all in this document.
>         o Part of the point is that if we can live with these points in
>respect of NAT,
>         these are not necessarily reasons to deprecate NAT-PT.  NAT solves
>an ongoing
>         problem in IPv4 whereas NAT-PT is intended to be a transition aid.
>On
>         the one hand we may feel it is easier to live with some issues if
>the mechanism
>         is not with us for ever, but on the other should we use a mechanism
>that has
>         all these issues at all?

It depends on what the needs of the scenario is. For example, e2e security does
not work well but does some one care if they does not need security. Should 
that
be a reason to deprecate ? Documenting and noting the issues that are common
to NAT and NAT-PT are fine but using them as the reasons to deprecate NAT-PT
does not make sense to me. The reasons to deprecate NAT-PT should be the
reasons that are unique to NAT-PT.

>       o Also these issues will apply to *any* translation mechanism rather
>than just
>         the SIIT + DNS-ALG version which we the document is trying to
>justify
>         deprecating
>My view is that the issues should be called out in the document, but we
>should make it more clear that they will apply to any translation mechanism
>as well.  I don't think it is good to have to point to a lot of v4 specific
>documents which cover other ground as well, particularly if we end up not
>deprecating NAT-PT completely.  Views are sought.

I agree.

>- How to handle the connection to all the prior drafts which are (partially)
>summarised in this document.  Is the current approach correct?

I am not very sure what new this document has brought out that the
other documents did not. The only section I see different from the previous
drafts is that there is an analysis section that states we recommend to
deprecate it for all of the above reasons.


>2. Use Cases for NAT-PT and other translation mechanisms
>- A number of use cases where NAT-PT is being used (whether appropriately or
>not) or is thought to be a possible solution were discussed. More input on
>other cases and details of identified cases has been asked for and is still
>wanted in some cases - please send in detailed info if possible.

As long as we can agree to the fact that there will be nodes/networks
that are v6only/v4 only and there will be a need for these nodes/networks
to talk to each other (your military scenario case is an example, wont be
the first and last), we will need a translation mechanism. You have also
mentioned that many of the issues identified is not specific to NAT-PT but
general translation issues. So it does not matter if we deprecate this and
write a brand new translation mechanism we will still inherit all the general
issues.



>- In some of these cases it looks as if NAT-PT is being used to solve a
>problem which it was not really intended (e.g. using back-to-back NAT-PTs to
>provide connection between (private) IPv4 domains across an IPv6 only
>backbone). I believe that NAT-PT was intended mainly to solve the problem of
>connecting an IPv4 only host/domain to an IPv6 only host/domain.  The
>back-to-back NAT-PT solution seems to be better covered by a 4 in 6
>tunneling solution.  Of course many of the issues called out in the draft do
>not apply in this situation because only the IP header needs translating and
>e2e IPsec will work because the packet is restored to its original form when
>it reaches the other end.  ALG's would not be required.  I am not clear that
>the standard form of the DNS-ALG proposed in 2766 applies to this use case.
>- Front ending a legacy v4 only server: This is clearly a good use for a
>straightforward translator, but there is little or no need for the
>generalised DNS-ALG in this case and the translator would generally have to
>handle a limited set of protocols and a limited set of v4 addresses defined
>by the server it was front ending.  This is not an application for the full
>generality of 2766 but I think we have to define a reduced version for this
>case.  Whether it is still called NAT-PT is a moot point.

Right, again this translator *will* be a subset of NAT-PT with all the issues
that a translator will have. (minus DNS-ALG specific issues).

>- The military case: I call it the military case but there are other related
>applications which have the same problem to solve.  As I see it the scenario
>involves a network of (newly created/adapted) v6 only devices that are
>unable to run dual stack because of resource constraints either in the
>devices or in the network connections.  These devices will, at least
>transiently, need to communicate with v4 devices in other domains (which
>have to remain v4 only for the same reasons of resource constraint).  The
>question is whether NAT-PT is the best technology to connect the domains.
>One question in my mind for the military case: The military specifically
>wanted to avoid putting NAT boxes in their  networks for good cause (single
>points of failure, routing constraints, security attack nexuses) - so why
>should they now want NAT-PT in their networks? On the other hand there will
>be at least some occasions when they have to work across domains during the
>transition, but ALGs/proxies may be a better solution given that these
>devices are likely to have a relatively limited set of applications.  There
>are also issues with using DNS in this sort of environment - it is a 'high
>availability/mobility' area and there may be worries about DNS caching
>lifetimes.  More input is needed here.

I think we could argue for ever over proxies vs NAT-PT, there is no clear 
documentation
that exists (atleast I am not aware of any), that concludes one way or the 
other.

>- 3GPP wireless: As mentioned in the draft, it may be better to consider
>using 4 in 6 or 6 in 4 tunnels to allow a single PDP context to carry both
>protocols.  This may require updates to RFC3314. More work is needed to
>ensure that header compression can reduce the impact on scarce bandwidth
>across the air interface (an extension of ROHC should be possible to cover
>tunnel headers).
>
>Do these cases cover all the expected scenarios?  Is the analysis correct?
>
>3. NAT-PT vs proxies
>Are proxies a better solution for most/all cases?  Either proxies or NAT-PT
>need to be extended to cope with new protocols in most cases.  Proxies may
>be more scalable (not all in the same box) and more adaptable to user needs
>(not dependent on a single vendor to do NAT-PT ALG upgrades). The most
>frequently used protocols today are HTTP, POP, SMTP, FTP and SSH: proxies
>are available for the first four - SSH is more problematic but is mostly a
>tool for power users (who are more likely to have dual stack support) and so
>SSH support may not be so important.
>
>Way forwards:
>- Tune the details
>- Show real examples, if any, where translators will really give better
>performance than proxies and are really vital. Make sure that backwards
>compatibility is fully considered, taking into account availability and
>migration of terminals from v4 to dual-stack/v6 plus the availability of
>tunnel support.
>- Either:
>    o Deprecate NAT-PT altogther and write other drafts with 'offspring of
>NAT-PT' to
>      cover the specialised use cases where a translator is useful, or

Same point as above, I am not sure how it would be free of all the translation
related issues.

>    o Turn this into a new applicability draft recommending only a very
>limited set
>      of uses, and produce modifications to cater for some of the specialised
>use cases.

I think that is what the previous applicability draft did.

>- Produce some recommendations on proxies and look to see which other
>proxies need specification (if any).
>- Ensure there are suitable specification(s) for 4 in 6 tunneling
>(configured, auto).
>- Ensure that the various scenario drafts recommend the 'right' solution.

Thanks
Senthil

>Regards,
>Elwyn
>
>----------------------------------------------------------------------------
>------
>
>Elwyn B Davies
>
>         Routing and Addressing Strategy Prime & IPv6 Core Team Leader
>         CTO Office, Portfolio Integration               Solutions Ready
>
>
>         Nortel Networks plc                     Email:
>elwynd@nortelnetworks.com
>         Harlow Laboratories                             ESN
>6-742-5498
>         London Road, Harlow,                            Direct Line
>+44-1279-405498
>         Essex, CM17 9NA, UK                     Fax
>+44-1279-402047
>         Registered Office:                      Maidenhead Office Park,
>Westacott Way,
>         Company No. 3937799                     Maidenhead, Berkshire, SSL6
>3QH
>----------------------------------------------------------------------------
>This message may contain information proprietary to Nortel Networks plc so
>any
>unauthorised disclosure, copying or distribution of its contents is strictly
>prohibited.
>----------------------------------------------------------------------------
>"The Folly is mostly mine"
>and the opinions are mine and not those of my employer.
>============================================================================
>======




From owner-v6ops@ops.ietf.org  Fri Nov  5 14:46:37 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10472
	for <v6ops-archive@lists.ietf.org>; Fri, 5 Nov 2004 14:46:37 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CQA20-000LcV-Oj
	for v6ops-data@psg.com; Fri, 05 Nov 2004 19:45:56 +0000
Received: from [66.54.152.27] (helo=jive.SoftHome.net)
	by psg.com with smtp (Exim 4.41 (FreeBSD))
	id 1CQA1z-000LcE-Qq
	for v6ops@ops.ietf.org; Fri, 05 Nov 2004 19:45:55 +0000
Received: (qmail 23405 invoked by uid 417); 5 Nov 2004 17:47:45 -0000
Received: from shunt-smtp-out-0 (HELO softhome.net) (172.16.3.12)
  by shunt-smtp-out-0 with SMTP; 5 Nov 2004 17:47:45 -0000
Received: from XPNERICK ([132.70.219.170])
  (AUTH: LOGIN ericlklein@softhome.net)
  by softhome.net with esmtp; Fri, 05 Nov 2004 10:47:43 -0700
Message-ID: <007d01c4c35f$68f51c60$0401a8c0@ttitelecom.com>
From: "EricLKlein" <ericlklein@softhome.net>
To: v6ops@ops.ietf.org
References: <Pine.LNX.4.61.0411040837210.3699@netcore.fi> <40D09F98-2EFA-11D9-AC14-00039376A6AA@sun.com> <Pine.LNX.4.61.0411051236240.9025@netcore.fi>
Subject: Re: A personal take on WG's priorities..
Date: Fri, 5 Nov 2004 19:46:38 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

If this seems to be a viable and accepted option, (and I realize 2 dozen
messages is not a mandate) lets look at splitting into sub teams (WGs) along
the lines of 1 / 2  and 3 / 4 so we can start closing things out for
standard status.

Eric

> On Thu, 4 Nov 2004, Alain Durand wrote:
> > Essentially, there is work needed in 4 areas:
> >
> > 1. Tunneling
> > - finish the work on assisted tunneling, zeroconf tunneling, 3GPP
tunneling
> > requirements
> > - finish the analysis of existing protocol candidates
> > - design new one(s) if needed
> > - finish the work on tunnel end-point discovery
> >
> > 2. Protocol maintenance
> > - deprecate useless mechanism
> > - clarify/refine some mechanism (e.g. 6to4)
> > - move some mechanisms along standard track
> >
> > 3. Operational issues
> > - renumbering doc
> > - IPv6 on by default
> > - operational security docs
> > - result from operational experience
> >
> > 4.  Finish the work on scenario.
> >
> > A natural evolution of NGtrans/v6ops would be to shut down v6Ops
> > by declaring victory on (4), and create two new working group,
> > a short to medium term one, focusing on (1) & (2), and a long  term one
> > focusing on 3.
>
> Pekka responded:
>
> 1 and 2 are certainly separable pieces of this puzzle.  However, it is
> important to put in place good policies on which kind of new tunneling
> work would be accepted (would it e.g., require a rechartering) so that
> the "v6mechs" WG would not become a "swamp".
>
> 3 and 4 are something that could be doable by "trimmed-down" v6ops;
> I'd see no particular use in shutting down a WG and springing up a new
> one in its place.  (4) needs to be finished, and there might be useful
> work coming down at that pipe down the road (like the BB ISP
> document).  I don't think the WG would need to initiate actively new
> work on 4, but if there were solid proposals on better documentation
> of existing scenarios, I don't see why that could not be documented.
>
>





From owner-v6ops@ops.ietf.org  Fri Nov  5 15:05:29 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11854
	for <v6ops-archive@lists.ietf.org>; Fri, 5 Nov 2004 15:05:28 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CQAKO-000OZd-0l
	for v6ops-data@psg.com; Fri, 05 Nov 2004 20:04:56 +0000
Received: from [66.54.152.27] (helo=jive.SoftHome.net)
	by psg.com with smtp (Exim 4.41 (FreeBSD))
	id 1CQAKN-000OZL-1x
	for v6ops@ops.ietf.org; Fri, 05 Nov 2004 20:04:55 +0000
Received: (qmail 14416 invoked by uid 417); 5 Nov 2004 18:07:39 -0000
Received: from shunt-smtp-out-0 (HELO softhome.net) (172.16.3.12)
  by shunt-smtp-out-0 with SMTP; 5 Nov 2004 18:07:39 -0000
Received: from XPNERICK ([132.70.219.170])
  (AUTH: LOGIN ericlklein@softhome.net)
  by softhome.net with esmtp; Fri, 05 Nov 2004 11:07:36 -0700
Message-ID: <015801c4c362$30085400$0401a8c0@ttitelecom.com>
From: "EricLKlein" <ericlklein@softhome.net>
To: v6ops@ops.ietf.org
References: <9C422444DE99BC46B3AD3C6EAFC9711B07C4C4F1@tayexc13.americas.cpqcorp.net> <418A766D.5080308@sun.com>
Subject: Re: Tunnel Discovery
Date: Fri, 5 Nov 2004 20:06:33 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Is there an interest in an off WG consolidation of these 3 into one or at
most 2 complementary documents that the WG would then review?

draft-yamamoto-naptr-service-discovery-00.txt
draft-ietf-v6ops-assisted-tunneling-requirements-01.txt
draft-palet-v6ops-solution-tun-auto-disc-01.txt

Sitting where I am in the NMS/OSS arena having these defined cleanly would
make my work much easier, so I would be consider helping with this.

Eric





From owner-v6ops@ops.ietf.org  Fri Nov  5 15:13:38 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13050
	for <v6ops-archive@lists.ietf.org>; Fri, 5 Nov 2004 15:13:38 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CQARs-000PnD-FM
	for v6ops-data@psg.com; Fri, 05 Nov 2004 20:12:40 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CQARr-000PmZ-6v
	for v6ops@ops.ietf.org; Fri, 05 Nov 2004 20:12:39 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id iA5KCTL23733;
	Fri, 5 Nov 2004 22:12:33 +0200
Date: Fri, 5 Nov 2004 22:12:29 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: Elwyn Davies <elwynd@nortelnetworks.com>
cc: "'v6ops@ops.ietf.org'" <v6ops@ops.ietf.org>
Subject: Re: NAT-PT: To deprecate or not to deprecate: the question for next
 w eek's v6ops discussion
In-Reply-To: <8F20221FB47FD51190AD00508BCF36BA0D4581FC@znsgy0k3.europe.nortel.com>
Message-ID: <Pine.LNX.4.61.0411052209060.23644@netcore.fi>
References: <8F20221FB47FD51190AD00508BCF36BA0D4581FC@znsgy0k3.europe.nortel.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

A third possibility could be,

On Fri, 5 Nov 2004, Elwyn Davies wrote:
>   o Deprecate NAT-PT altogther and write other drafts with 'offspring of
> NAT-PT' to
>     cover the specialised use cases where a translator is useful, or
>   o Turn this into a new applicability draft recommending only a very
> limited set
>     of uses, and produce modifications to cater for some of the specialised
> use cases.

(Writing strictly as another bozo on the bus..)

     o retain the tone of the draft, but instead of complete 
deprecation of NAT-PT, just classify it as Experimental.

There's precedent for that.  We want to send a clear message that 
NAT-PT is not good, but on the other hand, in some cases it might be 
the only alternative.

Experimental might do that: send a sufficiently clear signal, while 
still acknowledging that there may be somoe uses for it, and more 
investigation of the problem space might be warranted.

-- 
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 owner-v6ops@ops.ietf.org  Fri Nov  5 15:20:14 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13977
	for <v6ops-archive@lists.ietf.org>; Fri, 5 Nov 2004 15:20:13 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CQAYq-0000rb-54
	for v6ops-data@psg.com; Fri, 05 Nov 2004 20:19:52 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CQAYo-0000rF-O9
	for v6ops@ops.ietf.org; Fri, 05 Nov 2004 20:19:51 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id iA5KJgK23970;
	Fri, 5 Nov 2004 22:19:47 +0200
Date: Fri, 5 Nov 2004 22:19:42 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: EricLKlein <ericlklein@softhome.net>
cc: v6ops@ops.ietf.org
Subject: Re: Tunnel Discovery
In-Reply-To: <015801c4c362$30085400$0401a8c0@ttitelecom.com>
Message-ID: <Pine.LNX.4.61.0411052215000.23644@netcore.fi>
References: <9C422444DE99BC46B3AD3C6EAFC9711B07C4C4F1@tayexc13.americas.cpqcorp.net>
 <418A766D.5080308@sun.com> <015801c4c362$30085400$0401a8c0@ttitelecom.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

On Fri, 5 Nov 2004, EricLKlein wrote:
> Is there an interest in an off WG consolidation of these 3 into one or at
> most 2 complementary documents that the WG would then review?
>
> draft-yamamoto-naptr-service-discovery-00.txt
> draft-ietf-v6ops-assisted-tunneling-requirements-01.txt
> draft-palet-v6ops-solution-tun-auto-disc-01.txt

Umm.. isn't the middle one orthogonal to the other two?  There are 
likely some requirements for tunnel endpoint discovery in the middle 
one, yes, but that could not be merged in a solution.

(extremely personal view below)

More work towards the common solution is probably good, but personally 
I'm still quite a bit unconfortable with the fact that we have not 
analyzed the properties of different approaches -- in 
palet-v6ops-tun-auto-disc -- in a sufficient manner.  It seems 
premature to jump on to the solution space (especially with naptr 
approach which I'm personally most uncomfortable yet, at least).

-- 
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 owner-v6ops@ops.ietf.org  Fri Nov  5 15:33:41 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14990
	for <v6ops-archive@lists.ietf.org>; Fri, 5 Nov 2004 15:33:41 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CQAlh-000383-Im
	for v6ops-data@psg.com; Fri, 05 Nov 2004 20:33:09 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CQAlg-00037i-89
	for v6ops@ops.ietf.org; Fri, 05 Nov 2004 20:33:08 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id iA5KX1L24353;
	Fri, 5 Nov 2004 22:33:01 +0200
Date: Fri, 5 Nov 2004 22:33:01 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: Alain Durand <Alain.Durand@Sun.COM>
cc: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>, v6ops@ops.ietf.org
Subject: endpoint discovery from reverse DNS [Re: other comments on
 draft-nielsen-v6ops-3GPP-zeroconf-goals-00. txt
In-Reply-To: <418BC6E6.5010906@sun.com>
Message-ID: <Pine.LNX.4.61.0411052219540.23644@netcore.fi>
References: <BDB16935.4E3CE%jordi.palet@consulintel.es>
 <Pine.LNX.4.61.0411051901430.18349@netcore.fi> <418BC6E6.5010906@sun.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

These can certainly be argued many ways, and hopefully these issues 
can be captured in a revision of palet-tun-auto-disc..

On Fri, 5 Nov 2004, Alain Durand wrote:
>> As to the attributes of the reverse lookup schemes, one might say a few 
>> good / bad sides, like:
>>   - bad side is that requires a lot of records
>
>   not an issue as they can be generated with script.

Still, doing so either requires that script be invented and 
(re-)written by every DNS admin, or be distributed with DNS servers.
The script is probably very trivial, yes, but this is an ease-of-use 
factor.

If we want to make it extremely simple to set up these services this 
could be a small minus.

>>   - increases the number of required lookups
>
> Not necessarily. Think CNAME and additional section.

CNAMEs in reverse tree?  Granted.  Hopefully no DNS servers would 
break with such unanticipated usage.

>>   - on the other side, allows more flexible, IP-specific configuration
>> 
>> Also, two particular more generic issues, AFAIR, which could be discussed a 
>> bit more might be:
>> 
>>   - the "granularity" of the discovery process, i.e., how precisely and 
>> easily should you be able to modify the results of the lookup, e.g., tune 
>> that hosts A..B within a single administrative domain should discover X, 
>> hosts B..C should discover Y, etc. (for example, when using DNS, one way to 
>> achieve this would be split-faced DNS, or looking up stuff from the 
>> reverses like Alain proposes).
>
> In practice, I think this is an important operational issue.

Yes, it could be; depends a lot on how the network has been set up, 
who are in charge of the deployment of the tunnel endpoint (routing 
people, DNS people, or ...)

>>   - the manageability domain of the host.  It can be argued that IP 
>> addresses are often more "local" than host names.  A search path could 
>> include even all of the enterprise, all over the world, while customizing 
>> the lookup results (above) based on the IP address might go closer to the 
>> administrative domains.
>
> Search path are just plain wrong. As I explained several times, 
> internally at Sun, we have domains that span the planet and many 
> hosts are configured with several domains in their search path.

I don't see anything fundamentally *wrong* with the search path usage. 
Yes, under certain set-ups, it is difficult to discover *really* the 
closest relay just by using the DNS, but that's where routing can 
help.  Multiple searchpaths provide simple fallbacks as well.

>> It could also be argued that this may not be all that severe a problem 
>> here, if DNS is combined with anycast (provided that split DNS is not 
>> used).  Even if node X gets the same IP address everywhere by looking up 
>> x_srv.example.com, x_srv.example.com can be anycasted, set up everywhere 
>> using the same IP address.
>
> That makes the asumption that we know how to limit the propagation 
> of anycast routes within large domains. This is certainly doable, 
> but the associated complexity is large.

This seems simple routing basics.  Actually, you probably even don't 
need to propagate any host routes across different areas of a large 
domain.  Everyone just uses the same address to configure the 
topo/geographically distributed tunnel boxes, and it will go towards 
the closest one, either through a host route, or following the default 
route.

(Truth in advertising,) I see only a couple of minor problems with 
this:
  - if the number of boxes grows huge, beyond e.g. half a dozen, a 
large number of identically numbered boxes might get difficult, 
debugging-wise.  But as this is just a transition mechanism, it should 
be OK..
  - if the enterprise is divided to multiple autonomous systems or 
similar routing constructs, and you'd wish to deploy some boxes in 
those, and some out of them, the ingress filtering between the borders 
of those routing domains might get a bit complicated (might need to 
add one ACL line as an exception), depending on which IP address pool 
the address was taken from.

-- 
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 owner-v6ops@ops.ietf.org  Fri Nov  5 15:38:46 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15320
	for <v6ops-archive@lists.ietf.org>; Fri, 5 Nov 2004 15:38:46 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CQAqu-00044O-GX
	for v6ops-data@psg.com; Fri, 05 Nov 2004 20:38:32 +0000
Received: from [66.15.163.216] (helo=tndh.net)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CQAqt-00043X-3g
	for v6ops@ops.ietf.org; Fri, 05 Nov 2004 20:38:31 +0000
Received: from eaglet (127.0.0.1:4772)
	by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server]
	id <S76385> for <v6ops@ops.ietf.org> from <alh-ietf@tndh.net>;
	Fri, 5 Nov 2004 12:34:53 -0800
From: "Tony Hain" <alh-ietf@tndh.net>
To: "'Harald Tveit Alvestrand'" <harald@alvestrand.no>
Cc: <ietf@ietf.org>, "'Pekka Savola'" <pekkas@netcore.fi>,
        <v6ops@ops.ietf.org>
Subject: RE: Stepping down as IETF chair in March - & - RE: A personal take on WG's priorities..
Date: Fri, 5 Nov 2004 12:38:21 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-Reply-To: <705B3DE78CFF6BE932085A65@B50854F0A9192E8EC6CDA126>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcTDG/G2jX9pLh+fTzuhUQFOfQ7oCQAWIIUw
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Message-Id: <E1CQAqu-00044O-GX@psg.com>
Content-Transfer-Encoding: 7bit

Harald,

I would like to congratulate you on your successes, and suggest you have the
opportunity to be the last chair to preside over active work related to
version 4 of the IP protocol suite. With the publication of the tunneling
drafts that v6ops has been sitting on, there is no further need to discuss
32 bit address objects. At the same time, there is really no further
justification for any other IETF working group to be discussing 32 bit
addresses in current work. With all due respect to Geoff's efforts to
document the address growth rate in the routing system, even he acknowledges
that measure lags the allocation timeframe and assumes the RIRs will recover
all space currently considered lost. Given that IANA allocated 9 /8's over a
6 month period this year, coupled with the fact that only 78 /8's remain in
the useful part of the pool (ie: 52 month burn out), it should be clear to
everyone that products that rely on current standards activities will appear
in the market place after the central pool of 32 bit values has run dry. As
such I would recommend your legacy include an active review of all working
group discussions next week for items related to IPv4, followed by closure
of all 32 bit address related work items before your departure in March. 

Tony


> -----Original Message-----
> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of
> Harald Tveit Alvestrand
> Sent: Friday, November 05, 2004 1:20 AM
> To: ietf@ietf.org
> Subject: Stepping down as IETF chair in March
> 
> Thomas' note reminded me that there are probably some people who haven't
> heard this yet....
> 
> I'm stepping down as IETF chair in March, and I am not a candidate for
> reappointment.
> 
> It's been a great four years, containing lots of learning experience, lots
> of hard work and lots of joy - but after four years as IETF chair, and ten
> years total on the IESG/IAB, March seems an appropriate time for me to
> leave this stage of my life behind.
> 
> The IETF is a great organization. I will enjoy watching it continue to
> grow
> and prosper under new leadership.
> 
> Thank you!
> 
>                   Harald
> 
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf




From owner-v6ops@ops.ietf.org  Fri Nov  5 16:36:10 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20471
	for <v6ops-archive@lists.ietf.org>; Fri, 5 Nov 2004 16:36:09 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CQBj4-000Dkh-D7
	for v6ops-data@psg.com; Fri, 05 Nov 2004 21:34:30 +0000
Received: from [128.173.14.107] (helo=turing-police.cc.vt.edu)
 	by psg.com with esmtp (Exim 4.41 (FreeBSD))
 	id 1CQBgi-000DJs-L8
 	for v6ops@ops.ietf.org; Fri, 05 Nov 2004 21:32:04 +0000
Received: from turing-police.cc.vt.edu (IDENT:valdis@turing-police.cc.vt.edu [127.0.0.1])
 	by turing-police.cc.vt.edu (8.13.1/8.13.1) with ESMTP id iA5LVkFl006500;
 	Fri, 5 Nov 2004 16:31:46 -0500
Message-Id: <200411052131.iA5LVkFl006500@turing-police.cc.vt.edu>
X-Mailer: exmh version 2.7.1 10/11/2004 with nmh-1.1-RC3
To: Tony Hain <alh-ietf@tndh.net>
Cc: "'Harald Tveit Alvestrand'" <harald@alvestrand.no>, v6ops@ops.ietf.org,
        ietf@ietf.org, "'Pekka Savola'" <pekkas@netcore.fi>
Subject: Re: Stepping down as IETF chair in March - & - RE: A personal take on WG's priorities..
In-Reply-To: Your message of "Fri, 05 Nov 2004 12:38:21 PST."
              <200411052038.PAA15312@ietf.org>
From: Valdis.Kletnieks@vt.edu
References: <200411052038.PAA15312@ietf.org>
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="==_Exmh_-1358449488P";
 	 micalg=pgp-sha1; protocol="application/pgp-signature"
Content-Transfer-Encoding: 7bit
Date: Fri, 05 Nov 2004 16:31:46 -0500
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,NO_REAL_NAME
 	autolearn=no version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

--==_Exmh_-1358449488P
Content-Type: text/plain; charset=us-ascii

On Fri, 05 Nov 2004 12:38:21 PST, Tony Hain said:

> all space currently considered lost. Given that IANA allocated 9 /8's over a
> 6 month period this year, coupled with the fact that only 78 /8's remain in
> the useful part of the pool (ie: 52 month burn out),

They said that just before CIDR happened, too.

>From the routing-table summary posted to the NANOG list this morning:

Number of addresses announced to Internet:                   1348239976
     Equivalent to 80 /8s, 92 /16s and 130 /24s
     Percentage of available address space announced:               36.4
     Percentage of allocated address space announced:               58.8
     Percentage of available address space allocated:               61.9

So 40% isn't even *allocated* yet (saying that we're probably burning /8's
faster than needed, but only 36% of the available space is actually routed.

Sounds to me like we've got more time than 52 months, if we start doing
stuff now to increase the usage efficiencies....

--==_Exmh_-1358449488P
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Exmh version 2.5 07/13/2001

iD8DBQFBi/FCcC3lWbTT17ARAhC2AKDM2D03kPltXvfK53OEBA5DOIwyrwCbBvHj
3r7u+VsokH0hKHJR/sGi8zM=
=wm6z
-----END PGP SIGNATURE-----

--==_Exmh_-1358449488P--



From owner-v6ops@ops.ietf.org  Fri Nov  5 16:38:49 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20897
	for <v6ops-archive@lists.ietf.org>; Fri, 5 Nov 2004 16:38:49 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CQBn6-000EPV-Hu
	for v6ops-data@psg.com; Fri, 05 Nov 2004 21:38:40 +0000
Received: from [192.18.98.36] (helo=brmea-mail-4.sun.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CQBmw-000EMz-Nu
	for v6ops@ops.ietf.org; Fri, 05 Nov 2004 21:38:31 +0000
Received: from esunmail ([129.147.156.34])
	by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id iA5LcUNH014279
	for <v6ops@ops.ietf.org>; Fri, 5 Nov 2004 14:38:30 -0700 (MST)
Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM
 (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTP id <0I6Q00CWW6S5SR@edgemail1.Central.Sun.COM> for
 v6ops@ops.ietf.org; Fri, 05 Nov 2004 14:38:30 -0700 (MST)
Received: from [192.168.1.2] ([66.93.39.75])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I6Q005656S4HF@mail.sun.net> for v6ops@ops.ietf.org; Fri,
 05 Nov 2004 14:38:29 -0700 (MST)
Date: Fri, 05 Nov 2004 13:38:26 -0800
From: Alain Durand <Alain.Durand@Sun.COM>
Subject: Re: endpoint discovery from reverse DNS [Re: other comments on
 draft-nielsen-v6ops-3GPP-zeroconf-goals-00. txt
In-reply-to: <Pine.LNX.4.61.0411052219540.23644@netcore.fi>
To: Pekka Savola <pekkas@netcore.fi>
Cc: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>, v6ops@ops.ietf.org
Message-id: <06AD28D4-2F73-11D9-AC14-00039376A6AA@sun.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.619)
Content-type: text/plain; charset=US-ASCII; format=flowed
Content-transfer-encoding: 7BIT
References: <BDB16935.4E3CE%jordi.palet@consulintel.es>
 <Pine.LNX.4.61.0411051901430.18349@netcore.fi> <418BC6E6.5010906@sun.com>
 <Pine.LNX.4.61.0411052219540.23644@netcore.fi>
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7BIT


On Nov 5, 2004, at 12:33 PM, Pekka Savola wrote:

> These can certainly be argued many ways, and hopefully these issues 
> can be captured in a revision of palet-tun-auto-disc..
>
> On Fri, 5 Nov 2004, Alain Durand wrote:
>>> As to the attributes of the reverse lookup schemes, one might say a 
>>> few good / bad sides, like:
>>>   - bad side is that requires a lot of records
>>
>>   not an issue as they can be generated with script.
>
> Still, doing so either requires that script be invented and 
> (re-)written by every DNS admin, or be distributed with DNS servers.
> The script is probably very trivial, yes, but this is an ease-of-use 
> factor.

This is a bogus argument. Such a script already exist for generating 
the PTR in the reverse zone.
I wrote a very small ad-hoc perl script (10 lines of code!) to do that, 
I can donate it to the community
if need be.

Another way to solve this non-issue is to get $generate to be adapted 
to generate NAPTR as well.

> If we want to make it extremely simple to set up these services this 
> could be a small minus.
>
>>>   - increases the number of required lookups
>>
>> Not necessarily. Think CNAME and additional section.
>
> CNAMEs in reverse tree?  Granted.  Hopefully no DNS servers would 
> break with such unanticipated usage.

No. I should have been more clear...
When you are resolving a name in the forward tree and there is a CNAME, 
you generally do not
have to do a second query to resolve the CNAME. As the server knows you 
are more than likely to
need that data anyway, it puts it in the additional section. Example:
[halibut:~] alain% dig ftp.sun.com a

; <<>> DiG 9.2.2 <<>> ftp.sun.com a
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11219
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;ftp.sun.com.                   IN      A

;; ANSWER SECTION:
ftp.sun.com.            86400   IN      CNAME   supportfiles.sun.com.
supportfiles.sun.com.   86400   IN      A       192.18.108.101

;; Query time: 87 msec
;; SERVER: 64.81.79.2#53(64.81.79.2)
;; WHEN: Fri Nov  5 13:36:25 2004
;; MSG SIZE  rcvd: 72

	- Alain.




From owner-v6ops@ops.ietf.org  Fri Nov  5 16:48:41 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21938
	for <v6ops-archive@lists.ietf.org>; Fri, 5 Nov 2004 16:48:41 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CQBwQ-000G1a-Kl
	for v6ops-data@psg.com; Fri, 05 Nov 2004 21:48:18 +0000
Received: from [195.30.1.100] (helo=moebius2.Space.Net)
	by psg.com with smtp (Exim 4.41 (FreeBSD))
	id 1CQBwP-000G1M-EP
	for v6ops@ops.ietf.org; Fri, 05 Nov 2004 21:48:17 +0000
Received: (qmail 1805 invoked by uid 1007); 5 Nov 2004 21:48:16 -0000
Date: Fri, 5 Nov 2004 22:48:16 +0100
From: Gert Doering <gert@space.net>
To: Valdis.Kletnieks@vt.edu
Cc: Tony Hain <alh-ietf@tndh.net>,
        "'Harald Tveit Alvestrand'" <harald@alvestrand.no>, v6ops@ops.ietf.org,
        ietf@ietf.org, "'Pekka Savola'" <pekkas@netcore.fi>
Subject: Re: Stepping down as IETF chair in March - & - RE: A personal take on WG's priorities..
Message-ID: <20041105214816.GP84850@Space.Net>
References: <200411052038.PAA15312@ietf.org> <200411052131.iA5LVkFl006500@turing-police.cc.vt.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200411052131.iA5LVkFl006500@turing-police.cc.vt.edu>
User-Agent: Mutt/1.4.1i
X-NCC-RegID: de.space
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

Hi,

On Fri, Nov 05, 2004 at 04:31:46PM -0500, Valdis.Kletnieks@vt.edu wrote:
> So 40% isn't even *allocated* yet (saying that we're probably burning /8's
> faster than needed, but only 36% of the available space is actually routed.
> 
> Sounds to me like we've got more time than 52 months, if we start doing
> stuff now to increase the usage efficiencies....

Do we really *want* that?

I'd rather go for "legacy-free networks".  Ditch v4, build proper v6
networks.

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  66629  (65398)

SpaceNet AG                 Mail: netmaster@Space.Net
Joseph-Dollinger-Bogen 14   Tel : +49-89-32356-0
80807 Muenchen              Fax : +49-89-32356-299




From owner-v6ops@ops.ietf.org  Fri Nov  5 16:50:04 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22034
	for <v6ops-archive@lists.ietf.org>; Fri, 5 Nov 2004 16:50:03 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CQBxu-000GJ3-MQ
	for v6ops-data@psg.com; Fri, 05 Nov 2004 21:49:50 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CQBxt-000GIB-GO
	for v6ops@ops.ietf.org; Fri, 05 Nov 2004 21:49:49 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id iA5LniY26137;
	Fri, 5 Nov 2004 23:49:44 +0200
Date: Fri, 5 Nov 2004 23:49:44 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: Alain Durand <Alain.Durand@Sun.COM>
cc: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>, v6ops@ops.ietf.org
Subject: Re: endpoint discovery from reverse DNS [Re: other comments on
 draft-nielsen-v6ops-3GPP-zeroconf-goals-00. txt
In-Reply-To: <06AD28D4-2F73-11D9-AC14-00039376A6AA@sun.com>
Message-ID: <Pine.LNX.4.61.0411052342440.24972@netcore.fi>
References: <BDB16935.4E3CE%jordi.palet@consulintel.es>
 <Pine.LNX.4.61.0411051901430.18349@netcore.fi> <418BC6E6.5010906@sun.com>
 <Pine.LNX.4.61.0411052219540.23644@netcore.fi> <06AD28D4-2F73-11D9-AC14-00039376A6AA@sun.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

On Fri, 5 Nov 2004, Alain Durand wrote:
> On Nov 5, 2004, at 12:33 PM, Pekka Savola wrote:
>> On Fri, 5 Nov 2004, Alain Durand wrote:
>>>> As to the attributes of the reverse lookup schemes, one might say a few 
>>>> good / bad sides, like:
>>>>   - bad side is that requires a lot of records
>>> 
>>>   not an issue as they can be generated with script.
>> 
>> Still, doing so either requires that script be invented and (re-)written by 
>> every DNS admin, or be distributed with DNS servers.
>> The script is probably very trivial, yes, but this is an ease-of-use 
>> factor.
>
> This is a bogus argument. Such a script already exist for generating 
> the PTR in the reverse zone. I wrote a very small ad-hoc perl script 
> (10 lines of code!) to do that, I can donate it to the community if 
> need be.

I was not arguing that such scripts would not exist, and many admins 
would probably be qualified to write it pretty easily if they just 
bothered to do that.  The point is that the other admins don't know it 
exists when they think of the problem they want to solve, and 
discredit the solution as requiring manual insertion for the lack of 
better tools.

>>>>   - increases the number of required lookups
>>> 
>>> Not necessarily. Think CNAME and additional section.
>> 
>> CNAMEs in reverse tree?  Granted.  Hopefully no DNS servers would break 
>> with such unanticipated usage.
>
> No. I should have been more clear... When you are resolving a name 
> in the forward tree and there is a CNAME, you generally do not have 
> to do a second query to resolve the CNAME. As the server knows you 
> are more than likely to need that data anyway, it puts it in the 
> additional section.

Sure -- what I'm having difficulty understanding is why you're talking 
about forward tree when the proposal was about reverse tree?

-- 
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 owner-v6ops@ops.ietf.org  Fri Nov  5 16:58:10 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22817
	for <v6ops-archive@lists.ietf.org>; Fri, 5 Nov 2004 16:58:10 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CQC5e-000I6t-OQ
	for v6ops-data@psg.com; Fri, 05 Nov 2004 21:57:50 +0000
Received: from [128.173.14.107] (helo=turing-police.cc.vt.edu)
 	by psg.com with esmtp (Exim 4.41 (FreeBSD))
 	id 1CQC4t-000HzI-GS
 	for v6ops@ops.ietf.org; Fri, 05 Nov 2004 21:57:03 +0000
Received: from turing-police.cc.vt.edu (IDENT:valdis@turing-police.cc.vt.edu [127.0.0.1])
 	by turing-police.cc.vt.edu (8.13.1/8.13.1) with ESMTP id iA5LuuVG008224;
 	Fri, 5 Nov 2004 16:56:57 -0500
Message-Id: <200411052156.iA5LuuVG008224@turing-police.cc.vt.edu>
X-Mailer: exmh version 2.7.1 10/11/2004 with nmh-1.1-RC3
To: Gert Doering <gert@space.net>
Cc: Tony Hain <alh-ietf@tndh.net>,
        "'Harald Tveit Alvestrand'" <harald@alvestrand.no>, v6ops@ops.ietf.org,
        ietf@ietf.org, "'Pekka Savola'" <pekkas@netcore.fi>
Subject: Re: Stepping down as IETF chair in March - & - RE: A personal take on WG's priorities..
In-Reply-To: Your message of "Fri, 05 Nov 2004 22:48:16 +0100."
              <20041105214816.GP84850@Space.Net>
From: Valdis.Kletnieks@vt.edu
References: <200411052038.PAA15312@ietf.org> <200411052131.iA5LVkFl006500@turing-police.cc.vt.edu>
             <20041105214816.GP84850@Space.Net>
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="==_Exmh_-1346586936P";
 	 micalg=pgp-sha1; protocol="application/pgp-signature"
Content-Transfer-Encoding: 7bit
Date: Fri, 05 Nov 2004 16:56:56 -0500
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,NO_REAL_NAME
 	autolearn=no version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

--==_Exmh_-1346586936P
Content-Type: text/plain; charset=us-ascii

On Fri, 05 Nov 2004 22:48:16 +0100, Gert Doering said:
> Hi,
>
> On Fri, Nov 05, 2004 at 04:31:46PM -0500, Valdis.Kletnieks@vt.edu wrote:
>> So 40% isn't even *allocated* yet (saying that we're probably burning /8's
>> faster than needed, but only 36% of the available space is actually routed.
>>
>> Sounds to me like we've got more time than 52 months, if we start doing
>> stuff now to increase the usage efficiencies....
>
> Do we really *want* that?
>
> I'd rather go for "legacy-free networks".  Ditch v4, build proper v6
> networks.

Well.. that *would* be a preferable solution.  I was merely pointing out
that we're not quite as "up against the wall" as a projection of the burn
rate of /8's would indicate.

--==_Exmh_-1346586936P
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Exmh version 2.5 07/13/2001

iD8DBQFBi/cncC3lWbTT17ARAlrPAKDn1TVIrA+W3+KjJ6OPuNLA6+PdxQCeJz9+
7gpG8Y9mms1PMmK3dQWbxuk=
=oRJA
-----END PGP SIGNATURE-----

--==_Exmh_-1346586936P--



From owner-v6ops@ops.ietf.org  Fri Nov  5 17:01:44 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23332
	for <v6ops-archive@lists.ietf.org>; Fri, 5 Nov 2004 17:01:43 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CQC9D-000J6k-VA
	for v6ops-data@psg.com; Fri, 05 Nov 2004 22:01:31 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CQC9C-000J6O-Mi
	for v6ops@ops.ietf.org; Fri, 05 Nov 2004 22:01:31 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id iA5M0pw26489;
	Sat, 6 Nov 2004 00:00:52 +0200
Date: Sat, 6 Nov 2004 00:00:51 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: Tony Hain <alh-ietf@tndh.net>
cc: "'Harald Tveit Alvestrand'" <harald@alvestrand.no>, ietf@ietf.org,
        v6ops@ops.ietf.org
Subject: RE: Stepping down as IETF chair in March - & - RE: A personal take
 on WG's priorities..
In-Reply-To: <200411052038.iA5KcUq24455@netcore.fi>
Message-ID: <Pine.LNX.4.61.0411052358380.26364@netcore.fi>
References: <200411052038.iA5KcUq24455@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

Folks,

(v6ops WG co-chair hat on)

While this is an important and probably an entertaining topic when 
it's complete, it will be sufficient to discuss it at the IETF list.

Please DO NOT send further messages on v6ops list!

(hat off)


On Fri, 5 Nov 2004, Tony Hain wrote:
> I would like to congratulate you on your successes, and suggest you have the
> opportunity to be the last chair to preside over active work related to
> version 4 of the IP protocol suite. With the publication of the tunneling
> drafts that v6ops has been sitting on, there is no further need to discuss
> 32 bit address objects. At the same time, there is really no further
> justification for any other IETF working group to be discussing 32 bit
> addresses in current work. With all due respect to Geoff's efforts to
> document the address growth rate in the routing system, even he acknowledges
> that measure lags the allocation timeframe and assumes the RIRs will recover
> all space currently considered lost. Given that IANA allocated 9 /8's over a
> 6 month period this year, coupled with the fact that only 78 /8's remain in
> the useful part of the pool (ie: 52 month burn out), it should be clear to
> everyone that products that rely on current standards activities will appear
> in the market place after the central pool of 32 bit values has run dry. As
> such I would recommend your legacy include an active review of all working
> group discussions next week for items related to IPv4, followed by closure
> of all 32 bit address related work items before your departure in March.
>
> Tony
>
>
>> -----Original Message-----
>> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of
>> Harald Tveit Alvestrand
>> Sent: Friday, November 05, 2004 1:20 AM
>> To: ietf@ietf.org
>> Subject: Stepping down as IETF chair in March
>>
>> Thomas' note reminded me that there are probably some people who haven't
>> heard this yet....
>>
>> I'm stepping down as IETF chair in March, and I am not a candidate for
>> reappointment.
>>
>> It's been a great four years, containing lots of learning experience, lots
>> of hard work and lots of joy - but after four years as IETF chair, and ten
>> years total on the IESG/IAB, March seems an appropriate time for me to
>> leave this stage of my life behind.
>>
>> The IETF is a great organization. I will enjoy watching it continue to
>> grow
>> and prosper under new leadership.
>>
>> Thank you!
>>
>>                   Harald
>>
>> _______________________________________________
>> Ietf mailing list
>> Ietf@ietf.org
>> https://www1.ietf.org/mailman/listinfo/ietf
>

-- 
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 owner-v6ops@ops.ietf.org  Fri Nov  5 17:06:22 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23999
	for <v6ops-archive@lists.ietf.org>; Fri, 5 Nov 2004 17:06:21 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CQCDY-000JzK-W7
	for v6ops-data@psg.com; Fri, 05 Nov 2004 22:06:01 +0000
Received: from [192.18.98.36] (helo=brmea-mail-4.sun.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CQCDY-000Jyp-20
	for v6ops@ops.ietf.org; Fri, 05 Nov 2004 22:06:00 +0000
Received: from esunmail ([129.147.156.34])
	by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id iA5M5xNH029777
	for <v6ops@ops.ietf.org>; Fri, 5 Nov 2004 15:05:59 -0700 (MST)
Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM
 (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTP id <0I6Q00CP281YSR@edgemail1.Central.Sun.COM> for
 v6ops@ops.ietf.org; Fri, 05 Nov 2004 15:05:59 -0700 (MST)
Received: from [192.168.1.2] ([66.93.39.75])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I6Q005DU81XHF@mail.sun.net> for v6ops@ops.ietf.org; Fri,
 05 Nov 2004 15:05:58 -0700 (MST)
Date: Fri, 05 Nov 2004 14:05:57 -0800
From: Alain Durand <Alain.Durand@Sun.COM>
Subject: Re: endpoint discovery from reverse DNS [Re: other comments on
 draft-nielsen-v6ops-3GPP-zeroconf-goals-00. txt
In-reply-to: <Pine.LNX.4.61.0411052342440.24972@netcore.fi>
To: Pekka Savola <pekkas@netcore.fi>
Cc: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>, v6ops@ops.ietf.org
Message-id: <DE994B4C-2F76-11D9-AC14-00039376A6AA@sun.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.619)
Content-type: text/plain; charset=US-ASCII; format=flowed
Content-transfer-encoding: 7BIT
References: <BDB16935.4E3CE%jordi.palet@consulintel.es>
 <Pine.LNX.4.61.0411051901430.18349@netcore.fi> <418BC6E6.5010906@sun.com>
 <Pine.LNX.4.61.0411052219540.23644@netcore.fi>
 <06AD28D4-2F73-11D9-AC14-00039376A6AA@sun.com>
 <Pine.LNX.4.61.0411052342440.24972@netcore.fi>
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7BIT

On Nov 5, 2004, at 1:49 PM, Pekka Savola wrote:

>  The point is that the other admins don't know it exists when they 
> think of the problem they want to solve, and discredit the solution as 
> requiring manual insertion for the lack of better tools.

Honestly, this is FUD.

> Sure -- what I'm having difficulty understanding is why you're talking 
> about forward tree when the proposal was about reverse tree?

Because the fact that the suggested use of NAPTR is in the reverse tree 
DNS is irrelevant to the number of
packet exchange. In draft-yamamoto-naptr-service-discovery-00 the NAPTR 
record points to a name
that then must be resolve into an IPv4 address, thus the potential 
extra packet exchange that can be avoided
using the same 'trick' as CNAME, i.e. padding data in the additional 
section.

	- Alain,




From owner-v6ops@ops.ietf.org  Fri Nov  5 17:12:14 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24595
	for <v6ops-archive@lists.ietf.org>; Fri, 5 Nov 2004 17:12:14 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CQCJH-000Kpb-M0
	for v6ops-data@psg.com; Fri, 05 Nov 2004 22:11:55 +0000
Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CQCJG-000KpN-SE
	for v6ops@ops.ietf.org; Fri, 05 Nov 2004 22:11:54 +0000
Received: from sj-core-1.cisco.com (171.71.177.237)
  by sj-iport-2.cisco.com with ESMTP; 05 Nov 2004 14:22:48 -0800
Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iA5MBnom000453;
	Fri, 5 Nov 2004 14:11:49 -0800 (PST)
Received: from CSCOAMERA19540.cisco.com (stealth-10-32-244-221.cisco.com [10.32.244.221])
	by mira-sjc5-b.cisco.com (MOS 3.4.5-GR)
	with SMTP id AYS95913;
	Fri, 5 Nov 2004 14:15:21 -0800 (PST)
Message-Id: <6.1.2.0.2.20041105140329.04afc090@mira-sjc5-b.cisco.com>
X-Sender: fred@mira-sjc5-b.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0
Date: Fri, 05 Nov 2004 14:05:28 -0800
To: Gert Doering <gert@space.net>
From: Fred Baker <fred@cisco.com>
Subject: Re: Stepping down as IETF chair in March - & - RE: A personal
  take on WG's priorities..
Cc: Valdis.Kletnieks@vt.edu, Tony Hain <alh-ietf@tndh.net>,
        "'Harald Tveit Alvestrand'" <harald@alvestrand.no>, v6ops@ops.ietf.org,
        ietf@ietf.org, "'Pekka Savola'" <pekkas@netcore.fi>
In-Reply-To: <20041105214816.GP84850@Space.Net>
References: <200411052038.PAA15312@ietf.org>
 <200411052131.iA5LVkFl006500@turing-police.cc.vt.edu>
 <20041105214816.GP84850@Space.Net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

Guys - please...

maybe it's just me, but it seems like this thread should be something about 
Harald. Coopting it to the continued wars between various competing 
technology religions seems just a tad disrespectful.

Could you at least change the subject line if we're going to go into this 
rathole again?


At 10:48 PM 11/05/04 +0100, Gert Doering wrote:
>Hi,
>
>On Fri, Nov 05, 2004 at 04:31:46PM -0500, Valdis.Kletnieks@vt.edu wrote:
> > So 40% isn't even *allocated* yet (saying that we're probably burning /8's
> > faster than needed, but only 36% of the available space is actually routed.
> >
> > Sounds to me like we've got more time than 52 months, if we start doing
> > stuff now to increase the usage efficiencies....
>
>Do we really *want* that?
>
>I'd rather go for "legacy-free networks".  Ditch v4, build proper v6
>networks.
>
>Gert Doering
>         -- NetMaster
>--
>Total number of prefixes smaller than registry allocations:  66629  (65398)
>
>SpaceNet AG                 Mail: netmaster@Space.Net
>Joseph-Dollinger-Bogen 14   Tel : +49-89-32356-0
>80807 Muenchen              Fax : +49-89-32356-299




From owner-v6ops@ops.ietf.org  Fri Nov  5 19:44:08 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05766
	for <v6ops-archive@lists.ietf.org>; Fri, 5 Nov 2004 19:44:07 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CQEen-000JDh-FC
	for v6ops-data@psg.com; Sat, 06 Nov 2004 00:42:17 +0000
Received: from [66.15.163.216] (helo=tndh.net)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CQEem-000JBq-EC
	for v6ops@ops.ietf.org; Sat, 06 Nov 2004 00:42:16 +0000
Received: from eaglet (127.0.0.1:3942)
	by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server]
	id <S7643D> for <v6ops@ops.ietf.org> from <alh-ietf@tndh.net>;
	Fri, 5 Nov 2004 16:38:38 -0800
From: "Tony Hain" <alh-ietf@tndh.net>
To: <Valdis.Kletnieks@vt.edu>
Cc: <v6ops@ops.ietf.org>, "'Harald Tveit Alvestrand'" <harald@alvestrand.no>,
        <ietf@ietf.org>, "'Pekka Savola'" <pekkas@netcore.fi>
Subject: Facing reality
Date: Fri, 5 Nov 2004 16:42:04 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-Reply-To: <200411052131.iA5LVkFl006500@turing-police.cc.vt.edu>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcTDgCNgMIY1j+xvR3G9t/CO/yE+2QAFVwPg
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Message-Id: <E1CQEen-000JDh-FC@psg.com>
Content-Transfer-Encoding: 7bit

Valdis.Kletnieks@vt.edu wrote:
> On Fri, 05 Nov 2004 12:38:21 PST, Tony Hain said:
> 
> > all space currently considered lost. Given that IANA allocated 9 /8's
> over a
> > 6 month period this year, coupled with the fact that only 78 /8's remain
> in
> > the useful part of the pool (ie: 52 month burn out),
> 
> They said that just before CIDR happened, too.

and CIDR bought us time to get a replacement ready. 

> 
> >From the routing-table summary posted to the NANOG list this morning:
> 
> Number of addresses announced to Internet:                   1348239976
>     Equivalent to 80 /8s, 92 /16s and 130 /24s
>     Percentage of available address space announced:               36.4
>     Percentage of allocated address space announced:               58.8
>     Percentage of available address space allocated:               61.9
> 
> So 40% isn't even *allocated* yet (saying that we're probably burning /8's
> faster than needed, but only 36% of the available space is actually
routed.
> 
> Sounds to me like we've got more time than 52 months, if we start doing
> stuff now to increase the usage efficiencies....

Despite the desire to look for indicators that preclude having to learn
something new, it really doesn't matter how much of the space is routed.
What matters is the day someone new shows up to acquire space they intend to
route, only to find the reservoir dry. The number of routing entries is an
interesting operational measure, but what counts from a protocol viability
standpoint is the remaining useful space in the IANA pool.

We can always extend the lifetime of IPv4 by restricting the allocation
policies. The point is it is long past time to wake up and face the reality
that stricter conservation is directly contrary to expanding the reach and
capabilities of the global Internet. The IETF needs to be about developing a
growing and vibrant Internet, so resisting the inevitable change is counter
productive. In that light, it is time to remove the special status of
separate working groups for IPv6, and make it the default IP protocol for
all IETF work. 

Tony





From owner-v6ops@ops.ietf.org  Fri Nov  5 19:50:02 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06471
	for <v6ops-archive@lists.ietf.org>; Fri, 5 Nov 2004 19:50:01 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CQEm0-000KMi-FF
	for v6ops-data@psg.com; Sat, 06 Nov 2004 00:49:44 +0000
Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CQElz-000KMT-Gs
	for v6ops@ops.ietf.org; Sat, 06 Nov 2004 00:49:43 +0000
Received: from esunmail ([129.147.156.34])
	by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id iA60nhui013583
	for <v6ops@ops.ietf.org>; Fri, 5 Nov 2004 17:49:43 -0700 (MST)
Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM
 (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTP id <0I6Q00C4SFMUSR@edgemail1.Central.Sun.COM> for
 v6ops@ops.ietf.org; Fri, 05 Nov 2004 17:49:43 -0700 (MST)
Received: from [192.168.1.2] ([66.93.39.75])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I6Q00H1UFMTTA@mail.sun.net> for v6ops@ops.ietf.org; Fri,
 05 Nov 2004 17:49:42 -0700 (MST)
Date: Fri, 05 Nov 2004 16:49:39 -0800
From: Alain Durand <Alain.Durand@Sun.COM>
Subject: Re: NAT-PT: To deprecate or not to deprecate: the question for  next w
 eek's v6ops discussion
In-reply-to: <4.3.2.7.2.20041105110520.02b7b6c0@mira-sjcd-2.cisco.com>
To: Senthil Sivakumar <ssenthil@cisco.com>
Cc: Elwyn Davies <elwynd@nortelnetworks.com>,
        "'v6ops@ops.ietf.org'" <v6ops@ops.ietf.org>
Message-id: <BD289622-2F8D-11D9-88AE-00039376A6AA@sun.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.619)
Content-type: text/plain; charset=US-ASCII; format=flowed
Content-transfer-encoding: 7BIT
References: <4.3.2.7.2.20041105110520.02b7b6c0@mira-sjcd-2.cisco.com>
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7BIT


On Nov 5, 2004, at 11:33 AM, Senthil Sivakumar wrote:

>> 2. Use Cases for NAT-PT and other translation mechanisms
>> - A number of use cases where NAT-PT is being used (whether 
>> appropriately or
>> not) or is thought to be a possible solution were discussed. More 
>> input on
>> other cases and details of identified cases has been asked for and is 
>> still
>> wanted in some cases - please send in detailed info if possible.
>
> As long as we can agree to the fact that there will be nodes/networks
> that are v6only/v4 only and there will be a need for these 
> nodes/networks
> to talk to each other (your military scenario case is an example, wont 
> be
> the first and last), we will need a translation mechanism. You have 
> also
> mentioned that many of the issues identified is not specific to NAT-PT 
> but
> general translation issues. So it does not matter if we deprecate this 
> and
> write a brand new translation mechanism we will still inherit all the 
> general
> issues.

I think this is the crux of the issue. NAT-PT is not just NAT for v4 to 
v6.
Because of its design, it adds new issue to the plate of NAT.

IMHO, the way forward is not to pretend any translation v6->v4 is bad, 
but to declare
that the specific method described in RFC2766 is problematic and thus 
should be deprecated.

If real need for v6 to v4 (and vice versa) emerge, it will be time to 
look again at the issue,
maybe resurrect my NAT64 and NAT46 proposals or design something else.

	- Alain.




From owner-v6ops@ops.ietf.org  Sat Nov  6 01:21:13 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29902
	for <v6ops-archive@lists.ietf.org>; Sat, 6 Nov 2004 01:21:12 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CQJuV-000Ou3-Fo
	for v6ops-data@psg.com; Sat, 06 Nov 2004 06:18:51 +0000
Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com)
 	by psg.com with esmtp (Exim 4.41 (FreeBSD))
 	id 1CQCk0-000O8C-Uv
 	for v6ops@ops.ietf.org; Fri, 05 Nov 2004 22:39:32 +0000
Received: from sj-core-5.cisco.com (171.71.177.238)
   by sj-iport-2.cisco.com with ESMTP; 05 Nov 2004 14:50:27 -0800
Received: from gwzw2k01 (sjc-vpn5-131.cisco.com [10.21.88.131])
 	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id iA5MdScp010385;
 	Fri, 5 Nov 2004 14:39:29 -0800 (PST)
Message-Id: <200411052239.iA5MdScp010385@sj-core-5.cisco.com>
Reply-To: <gwz@cisco.com>
From: "Glen Zorn \(gwz\)" <gwz@cisco.com>
To: "'Fred Baker'" <fred@cisco.com>, "'Gert Doering'" <gert@space.net>
Cc: "'Harald Tveit Alvestrand'" <harald@alvestrand.no>,
        <Valdis.Kletnieks@vt.edu>, <ietf@ietf.org>,
        "'Tony Hain'" <alh-ietf@tndh.net>, <v6ops@ops.ietf.org>,
        "'Pekka Savola'" <pekkas@netcore.fi>
Subject: RE: Stepping down as IETF chair in March - & - RE: A personal take on WG's priorities..
Date: Fri, 5 Nov 2004 14:39:29 -0800
MIME-Version: 1.0
Content-Type: text/plain;
 	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
In-Reply-To: <6.1.2.0.2.20041105140329.04afc090@mira-sjc5-b.cisco.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300
Thread-Index: AcTDh5ArmxhkBXeaS/O5qaJGNoqdXwAAK/aw
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham
 	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Fred Baker <> wrote:
> Guys - please...
>
> maybe it's just me, but it seems like this thread should be
something
> about Harald. Coopting it to the continued wars between various
> competing technology religions seems just a tad disrespectful.
>
> Could you at least change the subject line if we're going to go
into
> this rathole again?

Well said.

>
>
> At 10:48 PM 11/05/04 +0100, Gert Doering wrote:
>> Hi,
>>
>> On Fri, Nov 05, 2004 at 04:31:46PM -0500, Valdis.Kletnieks@vt.edu
>> wrote:
>>> So 40% isn't even *allocated* yet (saying that we're probably
>>> burning /8's faster than needed, but only 36% of the available
>>> space is actually routed.
>>>
>>> Sounds to me like we've got more time than 52 months, if we
start
>>> doing stuff now to increase the usage efficiencies....
>>
>> Do we really *want* that?
>>
>> I'd rather go for "legacy-free networks".  Ditch v4, build proper
v6
>> networks.
>>
>> Gert Doering
>>         -- NetMaster
>> --
>> Total number of prefixes smaller than registry allocations:
66629
>> (65398)
>>
>> SpaceNet AG                 Mail: netmaster@Space.Net
>> Joseph-Dollinger-Bogen 14   Tel : +49-89-32356-0
>> 80807 Muenchen              Fax : +49-89-32356-299
>
>
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by
simply
   listening to John Coltrane? -- Henry Gabriel




From owner-v6ops@ops.ietf.org  Sat Nov  6 03:33:46 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22140
	for <v6ops-archive@lists.ietf.org>; Sat, 6 Nov 2004 03:33:45 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CQLz0-000IoW-8B
	for v6ops-data@psg.com; Sat, 06 Nov 2004 08:31:38 +0000
Received: from [66.54.152.27] (helo=jive.SoftHome.net)
	by psg.com with smtp (Exim 4.41 (FreeBSD))
	id 1CQLyz-000IoI-BV
	for v6ops@ops.ietf.org; Sat, 06 Nov 2004 08:31:37 +0000
Received: (qmail 29304 invoked by uid 417); 6 Nov 2004 08:24:04 -0000
Received: from charleston-.softhome.net (HELO softhome.net) (172.16.2.12)
  by shunt-smtp-out-0 with SMTP; 6 Nov 2004 08:24:04 -0000
Received: from XPNERICK ([132.70.219.170])
  (AUTH: LOGIN ericlklein@softhome.net)
  by softhome.net with esmtp; Sat, 06 Nov 2004 01:24:02 -0700
Message-ID: <001601c4c3d9$d469a770$0401a8c0@ttitelecom.com>
From: "EricLKlein" <ericlklein@softhome.net>
To: v6ops@ops.ietf.org
References: <4.3.2.7.2.20041105110520.02b7b6c0@mira-sjcd-2.cisco.com> <BD289622-2F8D-11D9-88AE-00039376A6AA@sun.com>
Subject: Re: NAT-PT: To deprecate or not to deprecate: the question for  next w eek's v6ops discussion
Date: Sat, 6 Nov 2004 10:22:59 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

From: "Alain Durand"
> I think this is the crux of the issue. NAT-PT is not just NAT for v4 to
> v6.
> Because of its design, it adds new issue to the plate of NAT.
>
> IMHO, the way forward is not to pretend any translation v6->v4 is bad,
> but to declare
> that the specific method described in RFC2766 is problematic and thus
> should be deprecated.
>
> If real need for v6 to v4 (and vice versa) emerge, it will be time to
> look again at the issue,
> maybe resurrect my NAT64 and NAT46 proposals or design something else.
>


I tend to disagree.

To borrow somthing Tony said in another thread:
"The IETF needs to be about developing a
growing and vibrant Internet, so resisting the inevitable change is counter
productive. In that light, it is time to remove the special status of
separate working groups for IPv6, and make it the default IP protocol for
all IETF work. "

Since we as a WG have decided to depriciate NAT and not support (allow) it
into IPv6 I think it is time that we just say that it is not supported and
start killing it off once and for all. Otherwise we will always have to work
the old NAT space and functions into the IPv6 space.

I understand the need for a transition mechanisim, but I do not feel that it
is strongly stated enough the NAT is out. Not even the why you don't need
NAT draft (draft-vandevelde-v6ops-nap-00) tries to do that.

We need to start pushing the new standards out to the market ASAP, or we
will be trying to back fix all sorts of propritary fixes (like the DHCPv6
issue) and will run out of addresses in the existing space ling before we
get real acceptance of IPv6.

Eric





From owner-v6ops@ops.ietf.org  Sat Nov  6 18:14:27 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15168
	for <v6ops-archive@lists.ietf.org>; Sat, 6 Nov 2004 18:14:26 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CQZiH-000181-R7
	for v6ops-data@psg.com; Sat, 06 Nov 2004 23:11:17 +0000
Received: from [63.103.94.23] (helo=ftmailgfi.flariontech.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CQZiG-00017k-Nf
	for v6ops@ops.ietf.org; Sat, 06 Nov 2004 23:11:16 +0000
Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Sat, 6 Nov 2004 18:10:56 -0500
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C4C455.DFB2038A"
Subject: RE: IPv4 consumption statistics and extrapolations
Date: Sat, 6 Nov 2004 18:10:57 -0500
Message-ID: <A11736FE943F1A408F8BBB1B9F5FE8ADC2B81D@ftmailserver.flariontech.com>
Thread-Topic: IPv4 consumption statistics and extrapolations
Thread-Index: AcTEP7OEekyqgxvpRAylxPwd4zWCsAACbqf1AALnWBA=
From: "Soliman, Hesham" <H.Soliman@flarion.com>
To: "Christian Huitema" <huitema@windows.microsoft.com>,
        "Bob Braden" <braden@ISI.EDU>, <harald@alvestrand.no>, <gih@apnic.net>
CC: <v6ops@ops.ietf.org>, <ietf@ietf.org>
X-OriginalArrivalTime: 06 Nov 2004 23:10:56.0857 (UTC) FILETIME=[DF2A4490:01C4C455]
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,
	HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

This is a multi-part message in MIME format.

------_=_NextPart_001_01C4C455.DFB2038A
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I think Christian made very important points.=20
I'd like to add one point that I'm sure will sound like a broken record =
to some=20
people. Mobile mobile mobile! There are more mobile devices today than =
IPv4
can handle, period. Everyone is using NATs to build their mobile =
networks. The question
here is will NATs survive the types of services that operators want to =
provide?=20
From where I'm looking, the problems are profound and extremely =
difficult to solve.=20
=20
I think the reason this hasn't been more widely understood is that we're =
still not close
to seeing those mobile peer to peer services over IP. But when that =
happens (no speculation
from me here), I think operators will realise what they're in for. This =
is especially true=20
for large operators.
=20
So, there is more to this than simply looking at the remaining address =
space and=20
the rates of allocation.
=20
Hesham

-----Original Message-----
From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org]On Behalf Of =
Christian Huitema
Sent: Saturday, November 06, 2004 5:06 PM
To: Bob Braden; harald@alvestrand.no; gih@apnic.net
Cc: v6ops@ops.ietf.org; ietf@ietf.org
Subject: RE: IPv4 consumption statistics and extrapolations


> Some 10 years ago, every IETF plenary meeting had a soothsayer =
session,
> projecting how soon we would run out of IPv4 addresses.  Has anyone
> looked to see how today's data extrapolates from the predictions then?
> Was it as "S" curve, after all??

There are two kinds of S curves, depending on what creates the =
asymptote. You may have an S curve that flattens when everybody is =
served (e.g. everybody on earth has a TV set), and another that flattens =
when the resource is exhausted (e.g. the last cod has been fished). =
Whether the address allocation falls in one or the other category will =
certainly be debated...
=20
As for extrapolating IANA assignment of /8 addresses, it is an =
interesting game. The data is available for everybody to look at =
http://www.iana.org/assignments/ipv4-address-space. If you sort =
allocations by date, you see three phases:
=20
- an initial allocation phase that ends in May 1993 when addresses start =
to be allocated by RIR using the CIDR policy. At the end of May 93, 94 =
prefixes are allocated or otherwise reserved.
- a relatively slow growth from May 93 to April 04, during which 50 new =
prefixes are allocated
- a recent spurt of activity causing 20 allocations between April and =
November 04.
=20
Depending over which period you average, we can argue that the =
allocation rate is:
- 6.8 per year between 1981 and 2004 (163 blocks divided by 24 years)
- 4.5 per year between May 1993 and April 2004 (50 blocks divided by 11)
- 6 per year between May 1993 and November 2003 (70 divided by 11.5)
- 34 per year lately (20 blocks over the course of 7 months)
I can assume that different soothsayers will pick different values, =
depending on whether they want to tell us that the sky is falling, or on =
the contrary that we should not worry.
=20
Another point of debate is how many blocks are actually available. Right =
now, 163 are in use, out of a total of 256, so we may assume that 93 are =
available. However, 16 of these blocks fall in the former "class E" =
category, and may or may not be easy to use...
=20
-- Christian Huitema


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D
This email may contain confidential and privileged material for the sole =
use
 of the intended recipient.  Any review or distribution by others is =
strictly
 prohibited.  If you are not the intended recipient please contact the =
sender
 and delete all copies.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D


------_=_NextPart_001_01C4C455.DFB2038A
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<TITLE>Re: IPv4 consumption statistics and extrapolations</TITLE>

<META content=3D"MSHTML 6.00.2900.2180" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D791010523-06112004><FONT face=3DArial color=3D#0000ff =
size=3D2>I=20
think Christian made very important points. </FONT></SPAN></DIV>
<DIV><SPAN class=3D791010523-06112004><FONT face=3DArial color=3D#0000ff =
size=3D2>I'd=20
like to add one point that I'm sure will sound like a broken record to =
some=20
</FONT></SPAN></DIV>
<DIV><SPAN class=3D791010523-06112004><FONT face=3DArial color=3D#0000ff =

size=3D2>people. Mobile mobile mobile! There are more mobile devices =
today than=20
IPv4</FONT></SPAN></DIV>
<DIV><SPAN class=3D791010523-06112004><FONT face=3DArial color=3D#0000ff =
size=3D2>can=20
handle, period. Everyone is using NATs to build their mobile networks. =
The=20
question</FONT></SPAN></DIV>
<DIV><SPAN class=3D791010523-06112004><FONT face=3DArial color=3D#0000ff =
size=3D2>here=20
is will NATs survive the types of services that operators want to =
provide?=20
</FONT></SPAN></DIV>
<DIV><SPAN class=3D791010523-06112004><FONT face=3DArial color=3D#0000ff =
size=3D2>From=20
where I'm looking, the problems are profound and extremely difficult to =
solve.=20
</FONT></SPAN></DIV>
<DIV><SPAN class=3D791010523-06112004><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D791010523-06112004><FONT face=3DArial color=3D#0000ff =
size=3D2>I=20
think the reason this hasn't been more widely understood is that we're =
still not=20
close</FONT></SPAN></DIV>
<DIV><SPAN class=3D791010523-06112004><FONT face=3DArial color=3D#0000ff =
size=3D2>to=20
seeing those mobile peer to peer services over IP. But when that happens =
(no=20
speculation</FONT></SPAN></DIV>
<DIV><SPAN class=3D791010523-06112004><FONT face=3DArial color=3D#0000ff =
size=3D2>from=20
me here), I think operators will realise what they're in for. This is =
especially=20
true </FONT></SPAN></DIV>
<DIV><SPAN class=3D791010523-06112004><FONT face=3DArial color=3D#0000ff =
size=3D2>for=20
large operators.</FONT></SPAN></DIV>
<DIV><SPAN class=3D791010523-06112004><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D791010523-06112004><FONT face=3DArial color=3D#0000ff =
size=3D2>So,=20
there is more to this than simply looking at the remaining address space =
and=20
</FONT></SPAN></DIV>
<DIV><SPAN class=3D791010523-06112004><FONT face=3DArial color=3D#0000ff =
size=3D2>the=20
rates of allocation.</FONT></SPAN></DIV>
<DIV><SPAN class=3D791010523-06112004><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D791010523-06112004><FONT face=3DArial color=3D#0000ff =

size=3D2>Hesham</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> =
ietf-bounces@ietf.org=20
  [mailto:ietf-bounces@ietf.org]<B>On Behalf Of </B>Christian=20
  Huitema<BR><B>Sent:</B> Saturday, November 06, 2004 5:06 =
PM<BR><B>To:</B> Bob=20
  Braden; harald@alvestrand.no; gih@apnic.net<BR><B>Cc:</B> =
v6ops@ops.ietf.org;=20
  ietf@ietf.org<BR><B>Subject:</B> RE: IPv4 consumption statistics and=20
  extrapolations<BR><BR></FONT></DIV>
  <DIV id=3DidOWAReplyText5238 dir=3Dltr>
  <DIV dir=3Dltr><FONT size=3D2><FONT face=3DArial>&gt; </FONT>Some 10 =
years ago,=20
  every IETF plenary meeting had a soothsayer session,<BR>&gt; =
projecting how=20
  soon we would run out of IPv4 addresses.&nbsp; Has anyone<BR>&gt; =
looked to=20
  see how today's data extrapolates from the predictions then?<BR>&gt; =
Was it as=20
  "S" curve, after all??<BR></FONT><FONT size=3D2></FONT></DIV>
  <DIV dir=3Dltr><FONT size=3D2>There are two kinds of S curves, =
depending on what=20
  creates the asymptote. You may have an S curve that flattens when =
everybody is=20
  served (e.g. everybody on earth has a TV set), and another that =
flattens when=20
  the resource is exhausted (e.g. the last&nbsp;cod has been fished). =
Whether=20
  the address allocation falls in one or the other category will =
certainly be=20
  debated...</FONT></DIV>
  <DIV dir=3Dltr><FONT size=3D2></FONT>&nbsp;</DIV>
  <DIV dir=3Dltr><FONT size=3D2>As for extrapolating IANA assignment of =
/8=20
  addresses, it is an interesting game. The data is available for =
everybody to=20
  look at <A=20
  =
href=3D"http://www.iana.org/assignments/ipv4-address-space">http://www.ia=
na.org/assignments/ipv4-address-space</A>.=20
  If you sort allocations by date, you see three phases:</FONT></DIV>
  <DIV dir=3Dltr><FONT size=3D2></FONT>&nbsp;</DIV>
  <DIV dir=3Dltr><FONT size=3D2>- an initial allocation phase that ends =
in May 1993=20
  when addresses start to be allocated by RIR using the CIDR policy. At =
the end=20
  of May 93, 94 prefixes are allocated or otherwise =
reserved.</FONT></DIV>
  <DIV dir=3Dltr><FONT size=3D2>- a relatively slow growth from May 93 =
to April 04,=20
  during which 50 new prefixes are allocated</FONT></DIV>
  <DIV dir=3Dltr><FONT size=3D2>- a recent spurt of activity causing 20 =
allocations=20
  between April and November 04.</FONT></DIV>
  <DIV dir=3Dltr><FONT size=3D2></FONT>&nbsp;</DIV>
  <DIV dir=3Dltr><FONT size=3D2>Depending over which period you average, =
we can=20
  argue that the allocation rate is:</FONT></DIV>
  <DIV dir=3Dltr><FONT size=3D2>- 6.8 per year between 1981 and 2004 =
(163 blocks=20
  divided by 24 years)</FONT></DIV>
  <DIV dir=3Dltr><FONT size=3D2>- 4.5 per year between May 1993 and =
April 2004 (50=20
  blocks divided by 11)</FONT></DIV>
  <DIV dir=3Dltr><FONT size=3D2>- 6 per year between May 1993 and =
November 2003 (70=20
  divided by 11.5)</FONT></DIV>
  <DIV dir=3Dltr><FONT size=3D2>- 34 per year lately (20 blocks over the =
course of 7=20
  months)</FONT></DIV>
  <DIV dir=3Dltr><FONT size=3D2>I can assume that different soothsayers =
will pick=20
  different values, depending on whether they want to tell us that the =
sky is=20
  falling, or on the contrary that we should not worry.</FONT></DIV>
  <DIV dir=3Dltr><FONT size=3D2></FONT>&nbsp;</DIV>
  <DIV dir=3Dltr><FONT size=3D2>Another point of debate is how many =
blocks are=20
  actually available. Right now, 163 are in use, out of a total of 256, =
so we=20
  may assume that 93 are available. However, 16 of these blocks fall in =
the=20
  former "class E" category, and may or may not be easy to =
use...</FONT></DIV>
  <DIV dir=3Dltr><FONT size=3D2></FONT>&nbsp;</DIV>
  <DIV dir=3Dltr><FONT size=3D2>-- Christian=20
Huitema</FONT></DIV></DIV></BLOCKQUOTE></BODY><!--[object_id=3D#flarion.c=
om#]--><P align=3Dcenter><FONT face=3DTahoma size=3D2><FONT =
color=3D#0000ff>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<BR>This email may contain =
confidential and privileged material for the sole<BR>use of the intended =
recipient.&nbsp; Any review or distribution by others is <BR>strictly =
prohibited.&nbsp; If you are not the intended recipient please =
contact<BR>the sender and delete all =
copies.<BR>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</FONT></FONT></P></HTML>

------_=_NextPart_001_01C4C455.DFB2038A--



From owner-v6ops@ops.ietf.org  Sun Nov  7 08:03:01 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16454
	for <v6ops-archive@lists.ietf.org>; Sun, 7 Nov 2004 08:03:01 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CQmeC-000KzL-Rr
	for v6ops-data@psg.com; Sun, 07 Nov 2004 12:59:56 +0000
Received: from [158.38.152.233] (helo=eikenes.alvestrand.no)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CQmeB-000Kz4-V5
	for v6ops@ops.ietf.org; Sun, 07 Nov 2004 12:59:56 +0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by eikenes.alvestrand.no (Postfix) with ESMTP
	id 303E161BED; Sun,  7 Nov 2004 13:59:55 +0100 (CET)
Received: from eikenes.alvestrand.no ([127.0.0.1])
 by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 01435-02; Sun,  7 Nov 2004 13:59:53 +0100 (CET)
Received: from halvestr-w2k02.emea.cisco.com (localhost.localdomain [127.0.0.1])
	by eikenes.alvestrand.no (Postfix) with ESMTP
	id 65DE261BE9; Sun,  7 Nov 2004 13:59:46 +0100 (CET)
Date: Sun, 07 Nov 2004 07:49:25 -0500
From: Harald Tveit Alvestrand <harald@alvestrand.no>
To: Christian Huitema <huitema@windows.microsoft.com>,
        "Soliman, Hesham" <H.Soliman@flarion.com>, Bob Braden <braden@ISI.EDU>,
        gih@apnic.net
Cc: v6ops@ops.ietf.org, ietf@ietf.org
Subject: RE: IPv4 consumption statistics and extrapolations
Message-ID: <6609E06FCF5AD28FF650E0E6@B50854F0A9192E8EC6CDA126>
In-Reply-To: <DAC3FCB50E31C54987CD10797DA511BA0BCC14F3@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com>
References: <DAC3FCB50E31C54987CD10797DA511BA0BCC14F3@WIN-MSG-10.wingroup.wi
 ndeploy.ntdev.microsoft.com>
X-Mailer: Mulberry/3.1.5 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by amavisd-new at alvestrand.no
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit



--On 6. november 2004 17:15 -0800 Christian Huitema 
<huitema@windows.microsoft.com> wrote:

> By the way, I must apologize. I had a bug in the spreadsheet that I used,
> and the numbers that I quoted are goofy. The consumption did increase
> during the last year, but not quite that fast. Let's say that, depending
> on which number you pick, the consumption per year is between 4 and 10
> blocks, which means an exhaustion in 10 to 15 years if the rates
> continue. But it also mean that we are de facto in the upper size of the
> S curve, because we have passed the 50% capacity point.

your remark reminds me of the red-and-black chart of allocated and routed 
addresses that someone (KC?) showed at an IETF plenary some years back.

Other people called it "proof that there is no problem".

I called it "halfway to Hell".







From nobody@london.dnstraffic.net  Sun Nov  7 11:07:53 2004
Received: from london.dnstraffic.net (london.dnsstraffic.net [65.254.35.58] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29781
	for <v6ops-archive@lists.ietf.org>; Sun, 7 Nov 2004 11:07:53 -0500 (EST)
Received: from nobody by london.dnstraffic.net with local (Exim 4.43)
	id 1CQotD-0006aI-Dc; Sun, 07 Nov 2004 10:23:35 -0500
Subject: Re:letter of introduction.
From: carol <carole_sole@circlemail.com>
X-Priority: 1 (Highest)
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: RLSP Mailer
Message-Id: <E1CQotD-0006aI-Dc@london.dnstraffic.net>
Date: Sun, 07 Nov 2004 10:23:35 -0500
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - london.dnstraffic.net
X-AntiAbuse: Original Domain - lists.ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [99 32273] / [47 12]
X-AntiAbuse: Sender Address Domain - london.dnstraffic.net
X-Source: ¶
X-Source-Args: /usr/local/apache/bin/httpd -DSSL 
X-Source-Dir: xx513clan.com:/public_html
Content-Transfer-Encoding: 7bit


From:Mrs Caroline Solange Haafkens of Netherlands
I am Mrs Caroline Solange Haafkens  from Netherlands.
I am married to Dr.Franklyn Haafkens who worked with
ChevronTexaco in Nigeria for twenty  years before he
died in the year 2000.We were married for twenty-seven
years without a child. He died during one of the riot
in the Niger delta region of Nigeria.He was held
hostage and slain to death by protesting youths of the
region.
Before his death we were both born again christians.Since his death I decided not to re-marry . When my late 
husband was alive he deposited the sum of (Eight Million six hundred thousand U.S.Dollars)with a bank in the Netherlands Presently, this money is still with the bank and the management just wrote me as the beneficiary to come
forward to receive the money or rather issue a letter
of authorisation to somebody to receive it on my
behalf if I can not come over.

Presently, I'm with my laptop in a hospital where I
have been undergoing treatment for cancer of the lungs. I have since lost my  ability to talk and my doctors have told me that I have only a few months to live.
It is my last wish to see that this money is invested
the proceed at the end of every year distributed among
charity organisation.
I want a person that is God fearing that will use this
money to fund churches,orphanages and widows propagating the word of God and to ensure that the house of God is maintained. The Bible made us to understand that Blessed is the hand that giveth.I took this decision 
because i know that there are alot of poor people suffering from different kind of disease and nobody to come to their aid.
With God all things are possible. As soon as I receive
your reply I shall give you the contact of the bank.
 I will also issue you a letter of authority that will
prove you as the new beneficiary of this fund.You are
to help me invest this funds into real estate and
stocks.You will be entitled to 10% of every profit you
make in a year.  
Please assure me that you will act accordingly as I
stated herein.
Hoping to hearing from you soon.
waiting for your reply

Yours in Christ,
Mrs Caroline Solange Haafkens




___________________________________________________________________________
Mail sent from WebMail service at PHP-Nuke Powered Site xx513clanr
- http://xx513clan.com


From owner-v6ops@ops.ietf.org  Sun Nov  7 15:39:38 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22775
	for <v6ops-archive@lists.ietf.org>; Sun, 7 Nov 2004 15:39:37 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CQtml-00033w-Ba
	for v6ops-data@psg.com; Sun, 07 Nov 2004 20:37:15 +0000
Received: from [66.15.163.216] (helo=tndh.net)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CQtmj-000339-T4
	for v6ops@ops.ietf.org; Sun, 07 Nov 2004 20:37:14 +0000
Received: from eaglet (127.0.0.1:3583)
	by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server]
	id <S76991> for <v6ops@ops.ietf.org> from <alh-ietf@tndh.net>;
	Sun, 7 Nov 2004 12:33:30 -0800
From: "Tony Hain" <alh-ietf@tndh.net>
To: "'Geoff Huston'" <gih@apnic.net>,
        "'Harald Tveit Alvestrand'" <harald@alvestrand.no>
Cc: <v6ops@ops.ietf.org>, <ietf@ietf.org>,
        "'Pekka Savola'" <pekkas@netcore.fi>
Subject: RE: IPv4 consumption statistics and extrapolations
Date: Sun, 7 Nov 2004 12:36:53 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-Reply-To: <6.0.1.1.2.20041107065109.02379a00@localhost>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcTEPDib1mHlvzqBS8afM5rzYMhSTQAxSA+g
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Message-Id: <E1CQtml-00033w-Ba@psg.com>
Content-Transfer-Encoding: 7bit

Geoff Huston wrote:
> I would like to correct a few numbers in Tony's comments based on my work
> in this area that Tony has referred to.
> 
> The least squares best fit of advertised address space in the IPv4 domain
> over the past 5 years is a consumption rate of 4 /8s per year, slightly
> less than half of Tony's number

To continue the refinement; as you frequently point out as well, there is a
lag between request/assignment from the RIR and advertisement. Given that,
the advertisement growth you are quoting does not account for the recent
slope change in the IANA pool depletion I am referencing, and won't even
start to do so for another 6-12 months. 

> 
> Even over the past 10 months the least squares best fit of data is a
> consumption rate of 5.5/8's per year

Let's be clear, consumption rate from the pool is not the same as
advertisement rate you are basing your measurements on. The size of the
advertised pool has absolutely no bearing on the size of the remaining stock
held by IANA or the RIR's. The slopes may be on a time delayed track, but
there is always the opportunity for addresses to be pulled from the pool yet
never advertised. As my I-D on 1918bis points out there are organizations
that have outgrown the available private space, so there only current option
is to acquire public space they never intend to route.

> 
> At this rate the central pool will exhaust in 2018, some 14 years hence.

No, by your measure this is the date the advertised pool will be receiving
all possible prefixes. As we have discussed before, there are two problems
with these numbers, the first is that it assumes all currently reserved /8
prefixes can and will be used (by my count there were really only 78 useful
ones left in August), and second that it assumes that someone will find and
reclaim the ~13% of the space currently 'lost in the system' (the difference
between the IANA reserved and RIR-assigned).

> i.e. some 168 months hence. Allowing for an accelerating consumption rate
> at an exponential rate brings this forward to 10 years, or 120 months.
> (details of the analysis are at http://bgp.potaroo.net/ipv4/)
> 
> (Of course you should consult your favourite oracle, mystic, soothsayer or
> whatever for your own preferred version of the future.)

We can probably all agree that the 'last IPv4 address' will never be
acquired. Policies will become stricter until the price is so high that
nobody can afford it; or nobody will care once the replacement is deployed.

Tony 

> 
> regards,
> 
>     Geoff
> 
> 
> At 07:38 AM 6/11/2004, Tony Hain wrote:
> >Harald,
> >
> >I would like to congratulate you on your successes, and suggest you have
> the
> >opportunity to be the last chair to preside over active work related to
> >version 4 of the IP protocol suite. With the publication of the tunneling
> >drafts that v6ops has been sitting on, there is no further need to
> discuss
> >32 bit address objects. At the same time, there is really no further
> >justification for any other IETF working group to be discussing 32 bit
> >addresses in current work. With all due respect to Geoff's efforts to
> >document the address growth rate in the routing system, even he
> acknowledges
> >that measure lags the allocation timeframe and assumes the RIRs will
> recover
> >all space currently considered lost. Given that IANA allocated 9 /8's
> over a
> >6 month period this year, coupled with the fact that only 78 /8's remain
> in
> >the useful part of the pool (ie: 52 month burn out), it should be clear
> to
> >everyone that products that rely on current standards activities will
> appear
> >in the market place after the central pool of 32 bit values has run dry.
> As
> >such I would recommend your legacy include an active review of all
> working
> >group discussions next week for items related to IPv4, followed by
> closure
> >of all 32 bit address related work items before your departure in March.
> >
> >Tony
> >
> >
> > > -----Original Message-----
> > > From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf
> Of
> > > Harald Tveit Alvestrand
> > > Sent: Friday, November 05, 2004 1:20 AM
> > > To: ietf@ietf.org
> > > Subject: Stepping down as IETF chair in March
> > >
> > > Thomas' note reminded me that there are probably some people who
> haven't
> > > heard this yet....
> > >
> > > I'm stepping down as IETF chair in March, and I am not a candidate for
> > > reappointment.
> > >
> > > It's been a great four years, containing lots of learning experience,
> lots
> > > of hard work and lots of joy - but after four years as IETF chair, and
> ten
> > > years total on the IESG/IAB, March seems an appropriate time for me to
> > > leave this stage of my life behind.
> > >
> > > The IETF is a great organization. I will enjoy watching it continue to
> > > grow
> > > and prosper under new leadership.
> > >
> > > Thank you!
> > >
> > >                   Harald
> > >
> > > _______________________________________________
> > > Ietf mailing list
> > > Ietf@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/ietf
> >
> >
> >_______________________________________________
> >Ietf mailing list
> >Ietf@ietf.org
> >https://www1.ietf.org/mailman/listinfo/ietf
> 
> 
> 
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf




From owner-v6ops@ops.ietf.org  Sun Nov  7 16:12:24 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25875
	for <v6ops-archive@lists.ietf.org>; Sun, 7 Nov 2004 16:12:24 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CQuKG-0007ok-HV
	for v6ops-data@psg.com; Sun, 07 Nov 2004 21:11:52 +0000
Received: from [193.180.251.53] (helo=eagle.ericsson.se)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CQuKF-0007oW-Cc
	for v6ops@ops.ietf.org; Sun, 07 Nov 2004 21:11:51 +0000
Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121])
	by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id iA7LBoR2020097
	for <v6ops@ops.ietf.org>; Sun, 7 Nov 2004 22:11:50 +0100
Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211);
	 Sun, 7 Nov 2004 22:11:49 +0100
Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id WB159JLD; Sun, 7 Nov 2004 22:11:49 +0100
Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <J4ND1VKP>; Sun, 7 Nov 2004 22:11:49 +0100
Message-ID: <C26BB8276599A44B85D52F9CE41035E1050B9809@esealnt944.al.sw.ericsson.se>
X-Sybari-Trust: e057eedf 8cefd49f 19e455e7 00000138
From: "Karen E. Nielsen (AH/LMD)" <karen.e.nielsen@ericsson.com>
To: "'Alain.Durand@Sun.COM'" <Alain.Durand@Sun.COM>,
        Pekka Savola
	 <pekkas@netcore.fi>
Cc: "'''IPv6 Operations ' ' '" <v6ops@ops.ietf.org>
Subject: RE: other comments on draft-nielsen-v6ops-3GPP-zeroconf-goals-00.
	 txt
Date: Sun, 7 Nov 2004 22:11:48 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
X-OriginalArrivalTime: 07 Nov 2004 21:11:49.0610 (UTC) FILETIME=[657CACA0:01C4C50E]
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

Alain, Pekka, Jordi

I am fine with not referencing the NAPTR draft.

My original reasoning for referencing it was indeed that it wasn't referenced
in draft-palet-v6ops-tun-auto-disc-00.txt.

Thinking more on this issue on the way here, I actually have an additional
reason for not wanting to explicitly reference this particular solution in
the 3gpp-zeroconf draft at this stage in time.

The reason is that whereas for example the prefix'ed DNS search path approach analysed in
draft-palet-v6ops-tun-auto-disc-00.txt may be a good fit for the 3gpp environment, then
the more general NAPTR solution is less optimal from the 3gpp environment perspective
as it would require one additional RT compared to the 1 RT required by the prefix'ed DNS search path approach 
- this as one in the 3gpp environment possibly may assume that the end-user knows the Ipv4 domain name.

Now, I am not trying to say that the NAPTR cannot turn out to be the unified solution for 
server discovery - provided that we are going to have one unified solution, that is - but as
it doesn't seem to be the most optimal approach for the 3gpp environment, it would
be even more wrong to single it out as a solution in this document, I think.

BR, Karen
  

> -----Original Message-----
> From: Alain.Durand@Sun.COM [mailto:Alain.Durand@Sun.COM]
> Sent: Friday, November 05, 2004 6:31 PM
> To: Pekka Savola
> Cc: Karen E. Nielsen (AH/LMD); '''IPv6 Operations ' ' '
> Subject: Re: other comments on
> draft-nielsen-v6ops-3GPP-zeroconf-goals-00. txt
> 
> 
> Pekka Savola wrote:
> 
> > One comment on a comment,
> >
> > On Fri, 5 Nov 2004, Karen E. Nielsen (AH/LMD) wrote:
> >
> >>> Tunnel end-point discovery
> >>> -------------------------------------
> >>> This document should also reference
> >>> http://www.ietf.org/internet-drafts/draft-yamamoto-naptr-service-
> >>> discovery-00.txt
> >>>
> >>
> >> Yes, now it should. Thanks.
> >>
> >> Let me and the other authors think about how it should be put 
> >> exactly, I have a small concern with this in the 3gpp 
> environment due 
> >> to RT delays (more or that to come).
> >
> >
> > Let me disagree here, rather strongly.
> >
> > The requirements document like this should not point at various 
> > solutions documents.  In the case of tunnel endpoint discovery, we 
> > have a good document 
> (draft-palet-v6ops-tun-auto-disc-00.txt) -- which 
> > could include more discussion relating to draft-yamamoto-, 
> but there 
> > is no need to refer to that *HERE*.
> 
> We might be in violent agreement. My point is that either the 
> requirement specs reference
> all possible solutions or none and stick to requirements.
> Referencing only one potential solution is wrong.
> That said, I agree that all the tunnel end point discovery solutions 
> should be merged.
> 
>     - Alain.
> 



From owner-v6ops@ops.ietf.org  Sun Nov  7 16:18:52 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26532
	for <v6ops-archive@lists.ietf.org>; Sun, 7 Nov 2004 16:18:52 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CQuQg-0008RN-Vs
	for v6ops-data@psg.com; Sun, 07 Nov 2004 21:18:30 +0000
Received: from [66.15.163.216] (helo=tndh.net)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CQuQf-0008R2-PU
	for v6ops@ops.ietf.org; Sun, 07 Nov 2004 21:18:29 +0000
Received: from eaglet (127.0.0.1:3502)
	by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server]
	id <S769BC> for <v6ops@ops.ietf.org> from <alh-ietf@tndh.net>;
	Sun, 7 Nov 2004 13:14:50 -0800
From: "Tony Hain" <alh-ietf@tndh.net>
To: "'Geoff Huston'" <gih@apnic.net>,
        "'Harald Tveit Alvestrand'" <harald@alvestrand.no>
Cc: <v6ops@ops.ietf.org>, <ietf@ietf.org>,
        "'Pekka Savola'" <pekkas@netcore.fi>
Subject: RE: IPv4 consumption statistics and extrapolations
Date: Sun, 7 Nov 2004 13:18:12 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-Reply-To: <200411072037.PAA22590@ietf.org>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcTEPDib1mHlvzqBS8afM5rzYMhSTQAxSA+gAAMxWbA=
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Message-Id: <E1CQuQg-0008RN-Vs@psg.com>
Content-Transfer-Encoding: 7bit

And for further clarification... I put this response together based on the
data I saw from Geoff a couple of months ago, and couldn't check the URL in
the air. Everyone should check the site because he has included further
evaluation of the data. I apologize for any perception or inference that
Geoff may not have been presenting valid data. The data he has been
presenting is valid for what it measures, our differences of opinion have
been over what and where to measure.

That said, I stand by the point that if the recent depletion rate of 9 /8s
in 6 months holds, there are only 58 months left. That event may have been
an anomaly, or it may be the precursor to an even more accelerated run rate.
We won't know for several years which it was.

Tony


> -----Original Message-----
> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of
> Tony Hain
> Sent: Sunday, November 07, 2004 12:37 PM
> To: 'Geoff Huston'; 'Harald Tveit Alvestrand'
> Cc: v6ops@ops.ietf.org; ietf@ietf.org; 'Pekka Savola'
> Subject: RE: IPv4 consumption statistics and extrapolations
> 
> Geoff Huston wrote:
> > I would like to correct a few numbers in Tony's comments based on my
> work
> > in this area that Tony has referred to.
> >
> > The least squares best fit of advertised address space in the IPv4
> domain
> > over the past 5 years is a consumption rate of 4 /8s per year, slightly
> > less than half of Tony's number
> 
> To continue the refinement; as you frequently point out as well, there is
> a
> lag between request/assignment from the RIR and advertisement. Given that,
> the advertisement growth you are quoting does not account for the recent
> slope change in the IANA pool depletion I am referencing, and won't even
> start to do so for another 6-12 months.
> 
> >
> > Even over the past 10 months the least squares best fit of data is a
> > consumption rate of 5.5/8's per year
> 
> Let's be clear, consumption rate from the pool is not the same as
> advertisement rate you are basing your measurements on. The size of the
> advertised pool has absolutely no bearing on the size of the remaining
> stock
> held by IANA or the RIR's. The slopes may be on a time delayed track, but
> there is always the opportunity for addresses to be pulled from the pool
> yet
> never advertised. As my I-D on 1918bis points out there are organizations
> that have outgrown the available private space, so there only current
> option
> is to acquire public space they never intend to route.
> 
> >
> > At this rate the central pool will exhaust in 2018, some 14 years hence.
> 
> No, by your measure this is the date the advertised pool will be receiving
> all possible prefixes. As we have discussed before, there are two problems
> with these numbers, the first is that it assumes all currently reserved /8
> prefixes can and will be used (by my count there were really only 78
> useful
> ones left in August), and second that it assumes that someone will find
> and
> reclaim the ~13% of the space currently 'lost in the system' (the
> difference
> between the IANA reserved and RIR-assigned).
> 
> > i.e. some 168 months hence. Allowing for an accelerating consumption
> rate
> > at an exponential rate brings this forward to 10 years, or 120 months.
> > (details of the analysis are at http://bgp.potaroo.net/ipv4/)
> >
> > (Of course you should consult your favourite oracle, mystic, soothsayer
> or
> > whatever for your own preferred version of the future.)
> 
> We can probably all agree that the 'last IPv4 address' will never be
> acquired. Policies will become stricter until the price is so high that
> nobody can afford it; or nobody will care once the replacement is
deployed.
> 
> Tony
> 
> >
> > regards,
> >
> >     Geoff
> >
> >
> > At 07:38 AM 6/11/2004, Tony Hain wrote:
> > >Harald,
> > >
> > >I would like to congratulate you on your successes, and suggest you
> have
> > the
> > >opportunity to be the last chair to preside over active work related to
> > >version 4 of the IP protocol suite. With the publication of the
> tunneling
> > >drafts that v6ops has been sitting on, there is no further need to
> > discuss
> > >32 bit address objects. At the same time, there is really no further
> > >justification for any other IETF working group to be discussing 32 bit
> > >addresses in current work. With all due respect to Geoff's efforts to
> > >document the address growth rate in the routing system, even he
> > acknowledges
> > >that measure lags the allocation timeframe and assumes the RIRs will
> > recover
> > >all space currently considered lost. Given that IANA allocated 9 /8's
> > over a
> > >6 month period this year, coupled with the fact that only 78 /8's
> remain
> > in
> > >the useful part of the pool (ie: 52 month burn out), it should be clear
> > to
> > >everyone that products that rely on current standards activities will
> > appear
> > >in the market place after the central pool of 32 bit values has run
dry.
> > As
> > >such I would recommend your legacy include an active review of all
> > working
> > >group discussions next week for items related to IPv4, followed by
> > closure
> > >of all 32 bit address related work items before your departure in
March.
> > >
> > >Tony
> > >
> > >
> > > > -----Original Message-----
> > > > From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf
> > Of
> > > > Harald Tveit Alvestrand
> > > > Sent: Friday, November 05, 2004 1:20 AM
> > > > To: ietf@ietf.org
> > > > Subject: Stepping down as IETF chair in March
> > > >
> > > > Thomas' note reminded me that there are probably some people who
> > haven't
> > > > heard this yet....
> > > >
> > > > I'm stepping down as IETF chair in March, and I am not a candidate
> for
> > > > reappointment.
> > > >
> > > > It's been a great four years, containing lots of learning
experience,
> > lots
> > > > of hard work and lots of joy - but after four years as IETF chair,
> and
> > ten
> > > > years total on the IESG/IAB, March seems an appropriate time for me
> to
> > > > leave this stage of my life behind.
> > > >
> > > > The IETF is a great organization. I will enjoy watching it continue
> to
> > > > grow
> > > > and prosper under new leadership.
> > > >
> > > > Thank you!
> > > >
> > > >                   Harald
> > > >
> > > > _______________________________________________
> > > > Ietf mailing list
> > > > Ietf@ietf.org
> > > > https://www1.ietf.org/mailman/listinfo/ietf
> > >
> > >
> > >_______________________________________________
> > >Ietf mailing list
> > >Ietf@ietf.org
> > >https://www1.ietf.org/mailman/listinfo/ietf
> >
> >
> >
> > _______________________________________________
> > Ietf mailing list
> > Ietf@ietf.org
> > https://www1.ietf.org/mailman/listinfo/ietf
> 
> 
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf




From owner-v6ops@ops.ietf.org  Sun Nov  7 16:19:29 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26620
	for <v6ops-archive@lists.ietf.org>; Sun, 7 Nov 2004 16:19:29 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CQuRY-0008VT-H7
	for v6ops-data@psg.com; Sun, 07 Nov 2004 21:19:24 +0000
Received: from [203.50.0.6] (helo=kahuna.telstra.net)
 	by psg.com with esmtp (Exim 4.41 (FreeBSD))
 	id 1CQWlU-0005qN-9e
 	for v6ops@ops.ietf.org; Sat, 06 Nov 2004 20:02:24 +0000
Received: from gihz1.apnic.net (kahuna.telstra.net [203.50.0.6])
 	by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id iA6Jxlcn069622;
 	Sun, 7 Nov 2004 07:00:12 +1100 (EST)
 	(envelope-from gih@apnic.net)
Message-Id: <6.0.1.1.2.20041107065109.02379a00@localhost>
X-Sender: gih@localhost
X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1
Date: Sun, 07 Nov 2004 06:59:57 +1100
To: "Tony Hain" <alh-ietf@tndh.net>,
        "'Harald Tveit Alvestrand'" <harald@alvestrand.no>
From: Geoff Huston <gih@apnic.net>
Subject: IPv4 consumption statistics and extrapolations
Cc: v6ops@ops.ietf.org, ietf@ietf.org, "'Pekka Savola'" <pekkas@netcore.fi>
In-Reply-To: <200411052038.PAA15312@ietf.org>
References: <705B3DE78CFF6BE932085A65@B50854F0A9192E8EC6CDA126>
  <200411052038.PAA15312@ietf.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham
 	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

I would like to correct a few numbers in Tony's comments based on my work
in this area that Tony has referred to.

The least squares best fit of advertised address space in the IPv4 domain
over the past 5 years is a consumption rate of 4 /8s per year, slightly
less than half of Tony's number

Even over the past 10 months the least squares best fit of data is a
consumption rate of 5.5/8's per year

At this rate the central pool will exhaust in 2018, some 14 years hence.
i.e. some 168 months hence. Allowing for an accelerating consumption rate
at an exponential rate brings this forward to 10 years, or 120 months.
(details of the analysis are at http://bgp.potaroo.net/ipv4/)

(Of course you should consult your favourite oracle, mystic, soothsayer or
whatever for your own preferred version of the future.)

regards,

     Geoff


At 07:38 AM 6/11/2004, Tony Hain wrote:
>Harald,
>
>I would like to congratulate you on your successes, and suggest you have the
>opportunity to be the last chair to preside over active work related to
>version 4 of the IP protocol suite. With the publication of the tunneling
>drafts that v6ops has been sitting on, there is no further need to discuss
>32 bit address objects. At the same time, there is really no further
>justification for any other IETF working group to be discussing 32 bit
>addresses in current work. With all due respect to Geoff's efforts to
>document the address growth rate in the routing system, even he acknowledges
>that measure lags the allocation timeframe and assumes the RIRs will recover
>all space currently considered lost. Given that IANA allocated 9 /8's over a
>6 month period this year, coupled with the fact that only 78 /8's remain in
>the useful part of the pool (ie: 52 month burn out), it should be clear to
>everyone that products that rely on current standards activities will appear
>in the market place after the central pool of 32 bit values has run dry. As
>such I would recommend your legacy include an active review of all working
>group discussions next week for items related to IPv4, followed by closure
>of all 32 bit address related work items before your departure in March.
>
>Tony
>
>
>> -----Original Message-----
>> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of
>> Harald Tveit Alvestrand
>> Sent: Friday, November 05, 2004 1:20 AM
>> To: ietf@ietf.org
>> Subject: Stepping down as IETF chair in March
>>
>> Thomas' note reminded me that there are probably some people who haven't
>> heard this yet....
>>
>> I'm stepping down as IETF chair in March, and I am not a candidate for
>> reappointment.
>>
>> It's been a great four years, containing lots of learning experience, lots
>> of hard work and lots of joy - but after four years as IETF chair, and ten
>> years total on the IESG/IAB, March seems an appropriate time for me to
>> leave this stage of my life behind.
>>
>> The IETF is a great organization. I will enjoy watching it continue to
>> grow
>> and prosper under new leadership.
>>
>> Thank you!
>>
>>                   Harald
>>
>> _______________________________________________
>> Ietf mailing list
>> Ietf@ietf.org
>> https://www1.ietf.org/mailman/listinfo/ietf
>
>
>_______________________________________________
>Ietf mailing list
>Ietf@ietf.org
>https://www1.ietf.org/mailman/listinfo/ietf





From owner-v6ops@ops.ietf.org  Sun Nov  7 16:19:53 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26717
	for <v6ops-archive@lists.ietf.org>; Sun, 7 Nov 2004 16:19:53 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CQuRp-0008cC-DA
	for v6ops-data@psg.com; Sun, 07 Nov 2004 21:19:41 +0000
Received: from [128.9.160.161] (helo=boreas.isi.edu)
 	by psg.com with esmtp (Exim 4.41 (FreeBSD))
 	id 1CQX0T-0007af-3x
 	for v6ops@ops.ietf.org; Sat, 06 Nov 2004 20:17:53 +0000
Received: from gra.isi.edu (gra.isi.edu [128.9.160.133])
 	by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id iA6KGri05505;
 	Sat, 6 Nov 2004 12:16:53 -0800 (PST)
From: Bob Braden <braden@ISI.EDU>
Received: (from braden@localhost)
 	by gra.isi.edu (8.9.3/8.8.6) id MAA05409;
 	Sat, 6 Nov 2004 12:16:53 -0800 (PST)
Date: Sat, 6 Nov 2004 12:16:53 -0800 (PST)
Message-Id: <200411062016.MAA05409@gra.isi.edu>
To: harald@alvestrand.no, gih@apnic.net
Subject: Re: IPv4 consumption statistics and extrapolations
Cc: v6ops@ops.ietf.org, ietf@ietf.org
X-Sun-Charset: US-ASCII
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: braden@isi.edu
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham
 	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk


   *>
   *> At this rate the central pool will exhaust in 2018, some 14 years hence.
   *> i.e. some 168 months hence. Allowing for an accelerating consumption rate
   *> at an exponential rate brings this forward to 10 years, or 120 months.
   *> (details of the analysis are at http://bgp.potaroo.net/ipv4/)
   *>
   *> (Of course you should consult your favourite oracle, mystic, soothsayer or
   *> whatever for your own preferred version of the future.)
   *>
   *> regards,
   *>
   *>     Geoff
   *>
   *>

Some 10 years ago, every IETF plenary meeting had a soothsayer session,
projecting how soon we would run out of IPv4 addresses.  Has anyone
looked to see how today's data extrapolates from the predictions then?
Was it as "S" curve, after all??

Just wondering...

Bob Braden



From owner-v6ops@ops.ietf.org  Sun Nov  7 16:20:21 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26895
	for <v6ops-archive@lists.ietf.org>; Sun, 7 Nov 2004 16:20:21 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CQuSP-0008hm-Gk
	for v6ops-data@psg.com; Sun, 07 Nov 2004 21:20:17 +0000
Received: from [166.84.151.72] (helo=snark.piermont.com)
 	by psg.com with esmtp (Exim 4.41 (FreeBSD))
 	id 1CQcqE-000P3x-Ku
 	for v6ops@ops.ietf.org; Sun, 07 Nov 2004 02:31:42 +0000
Received: by snark.piermont.com (Postfix, from userid 1000)
 	id 4D29BD9948; Sat,  6 Nov 2004 21:31:37 -0500 (EST)
To: Valdis.Kletnieks@vt.edu
Cc: Tony Hain <alh-ietf@tndh.net>, v6ops@ops.ietf.org,
        "'Harald Tveit Alvestrand'" <harald@alvestrand.no>, ietf@ietf.org,
        "'Pekka Savola'" <pekkas@netcore.fi>
Subject: Re: Stepping down as IETF chair in March - & - RE: A personal take
  on WG's priorities..
References: <200411052038.PAA15312@ietf.org>
 	<200411052131.iA5LVkFl006500@turing-police.cc.vt.edu>
From: "Perry E. Metzger" <perry@piermont.com>
Date: Sat, 06 Nov 2004 21:31:37 -0500
In-Reply-To: <200411052131.iA5LVkFl006500@turing-police.cc.vt.edu> (Valdis
  Kletnieks's message of "Fri, 05 Nov 2004 16:31:46 -0500")
Message-ID: <877joyl792.fsf@snark.piermont.com>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (berkeley-unix)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham
 	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk


Valdis.Kletnieks@vt.edu writes:
> On Fri, 05 Nov 2004 12:38:21 PST, Tony Hain said:
>
>> all space currently considered lost. Given that IANA allocated 9 /8's over a
>> 6 month period this year, coupled with the fact that only 78 /8's remain in
>> the useful part of the pool (ie: 52 month burn out),
>
> They said that just before CIDR happened, too.

We are already out of addresses. I cannot easily connect from my
laptop in my apartment (behind a NAT) with a friend's laptop in his
apartment (because it is also behind a NAT). This makes quickly
transferring pictures or documents from my machine to a friend's
machine a pain in the neck.

We ran out of addresses for practical purposes years ago. Anyone who
is running a NAT is doing so because it was easier to do that than to
try to get address space.

Perry



From owner-v6ops@ops.ietf.org  Sun Nov  7 16:20:43 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26955
	for <v6ops-archive@lists.ietf.org>; Sun, 7 Nov 2004 16:20:43 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CQuSk-0008or-Ni
	for v6ops-data@psg.com; Sun, 07 Nov 2004 21:20:38 +0000
Received: from [63.247.74.122] (helo=montage.altserver.com)
 	by psg.com with esmtp (Exim 4.41 (FreeBSD))
 	id 1CQduW-0007WA-MR
 	for v6ops@ops.ietf.org; Sun, 07 Nov 2004 03:40:12 +0000
Received: from [82.249.3.178] (helo=jfc.afrac.org)
 	by montage.altserver.com with esmtpa (Exim 4.43)
 	id 1CQduT-0006ZA-OF; Sat, 06 Nov 2004 19:40:10 -0800
Message-Id: <6.1.2.0.2.20041107040105.05822620@mail.jefsey.com>
X-Sender: jefsey+jefsey.com@mail.jefsey.com
X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0
Date: Sun, 07 Nov 2004 04:39:53 +0100
To: "Perry E. Metzger" <perry@piermont.com>, Valdis.Kletnieks@vt.edu
From: "JFC (Jefsey) Morfin" <jefsey@jefsey.com>
Subject: Re: Stepping down as IETF chair in March - & - RE: A personal
   take on WG's priorities..
Cc: v6ops@ops.ietf.org, "'Harald Tveit Alvestrand'" <harald@alvestrand.no>,
        ietf@ietf.org, Tony Hain <alh-ietf@tndh.net>,
        "'Pekka Savola'" <pekkas@netcore.fi>
In-Reply-To: <877joyl792.fsf@snark.piermont.com>
References: <200411052038.PAA15312@ietf.org>
  <200411052131.iA5LVkFl006500@turing-police.cc.vt.edu>
  <877joyl792.fsf@snark.piermont.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-5DE41D44
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - montage.altserver.com
X-AntiAbuse: Original Domain - ops.ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12]
X-AntiAbuse: Sender Address Domain - jefsey.com
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham
 	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

The need you describe is the true need of the users. What they discuss is
IPv6 as an IPv4 patch better than NATs. You discuss tier to tier exchanges.
This is almost a different vision of the network.

A vision IPv6 is properly design to support. The problem acknowledged by
Michel Py and Steve Crocker, and others, mainly comes from the "a la IPv4"
management of the IPv6 addressing plan. Innovation is blocked there. This
is to do with ICANN's IANA and numbering plan organization and
intergovernance, not with IPv6.

Please read Mr. Zhao's contribution drafts for ITU on the matter if you
find one (I understand that he plans releasing his position by
mid-November?). You document THE main need for IPv6: to permit a flexible
management of tier and tier universal relations. For a while NAT helped a
lot - and will continue and improve - at intranet level. But end-users need
much more: a full control, that only IPv6 can deliver, as you show it. When
an adequate IPv6 addressing plan is offered and used by end-users, NATs
will disappear as useless, costly and obsolete constraints.

You cannot change things on the internet, you can only improve them and
make them obsolete.
jfc

At 03:31 07/11/2004, Perry E. Metzger wrote:
>Valdis.Kletnieks@vt.edu writes:
>> On Fri, 05 Nov 2004 12:38:21 PST, Tony Hain said:
>>
>>> all space currently considered lost. Given that IANA allocated 9 /8's
> over a
>>> 6 month period this year, coupled with the fact that only 78 /8's
> remain in
>>> the useful part of the pool (ie: 52 month burn out),
>> They said that just before CIDR happened, too.
>
>We are already out of addresses. I cannot easily connect from my
>laptop in my apartment (behind a NAT) with a friend's laptop in his
>apartment (because it is also behind a NAT). This makes quickly
>transferring pictures or documents from my machine to a friend's
>machine a pain in the neck.
>
>We ran out of addresses for practical purposes years ago. Anyone who
>is running a NAT is doing so because it was easier to do that than to
>try to get address space.
>
>Perry
>
>_______________________________________________
>Ietf mailing list
>Ietf@ietf.org
>https://www1.ietf.org/mailman/listinfo/ietf




From owner-v6ops@ops.ietf.org  Sun Nov  7 16:30:57 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28194
	for <v6ops-archive@lists.ietf.org>; Sun, 7 Nov 2004 16:30:57 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CQucJ-000Akk-Qq
	for v6ops-data@psg.com; Sun, 07 Nov 2004 21:30:31 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CQucI-000AkN-Ik
	for v6ops@ops.ietf.org; Sun, 07 Nov 2004 21:30:31 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id iA7LTox23984;
	Sun, 7 Nov 2004 23:29:50 +0200
Date: Sun, 7 Nov 2004 23:29:50 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: ietf@ietf.org
cc: v6ops@ops.ietf.org
Subject: STOP CROSSPOSTING TO v6ops@ops.ietf.org !
Message-ID: <Pine.LNX.4.61.0411072323520.23241@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

(v6ops wg co-chair hat on)

I already said this once, but let me repeat more clearly.

STOP CROSS-POSTING those "v4 vs v6" debates to v6ops.  It's sufficient 
that these topics are discussed in *one* mailing list, and as these 
are generic issues, they are much better discussed only at the IETF 
list.

Until these debates clear off, do not cross-post anything to v6ops 
which is also posted to the IETF list!

(hat off)

-- 
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 owner-v6ops@ops.ietf.org  Sun Nov  7 18:51:21 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11725
	for <v6ops-archive@lists.ietf.org>; Sun, 7 Nov 2004 18:51:20 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CQwm2-0000ke-67
	for v6ops-data@psg.com; Sun, 07 Nov 2004 23:48:42 +0000
Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CQwm0-0000jJ-Bn
	for v6ops@ops.ietf.org; Sun, 07 Nov 2004 23:48:40 +0000
Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131])
	by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id iA7NmdGn028148
	for <v6ops@ops.ietf.org>; Sun, 7 Nov 2004 23:48:39 GMT
Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162])
	by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id XAA29369
	for <v6ops@ops.ietf.org>; Sun, 7 Nov 2004 23:48:37 GMT
Received: (from tjc@localhost)
	by login.ecs.soton.ac.uk (8.11.6/8.11.6) id iA7Nmbe21040
	for v6ops@ops.ietf.org; Sun, 7 Nov 2004 23:48:37 GMT
Date: Sun, 7 Nov 2004 23:48:37 +0000
From: Tim Chown <tjc@ecs.soton.ac.uk>
To: v6ops@ops.ietf.org
Subject: Comments on draft-suryanarayanan-v6ops-zeroconf-reqs-00
Message-ID: <20041107234837.GH19316@login.ecs.soton.ac.uk>
Mail-Followup-To: v6ops@ops.ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4i
X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information
X-ECS-MailScanner: Found to be clean
X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

Hi,

Some comments on this draft.   Overall I found it seemed overly long,
it meandered somewhat and lacked some focus, and included a number of
repeated chunks of text that could be saod in one place.


               Zero-Configuration Tunneling Requirements
            draft-suryanarayanan-v6ops-zeroconf-reqs-00.txt


>> Main comments:

>> 1. Not clear what scope is, e.g. single node or not, within the
      network of a single provider or not, is host-host zct supported
      or not, etc.

>> 2. Should state assumptions in one place/section, they are split
      across the document in many places.  This would include the
      two items in the "out of scope" appendix.

>> 3. Should list all requirements in one section and have the four
      scenarios refer to that, at present some scenarios have their
      own (sometimes repeated) requirements.

>> Specific comments:

1.  Introduction

   One of the major differences between the zero-configuration tunneling
   mechanism and the full-fledged tunneling mechanism is that the former
   does not support user authentication, which should not be an issue
   because the scope of the users of this mechanism are already users of
   the Service Provider actually deploying it.  Consequently, the users
   are to be authenticated by other means, which are out of the scope of
   this document.

>> Thus this zct solution is only for intra-provider solutions?  Just
   state that if it's the case.

>> Is this a solution for single nodes only?  If so, state that clearly
   early on.

   It should be emphasized that unless otherwise specified, in this
   document the reference, IPv6-in-IPv4 encapsulation as defined in [7],
   refers to the aspects of Protocol-41 encapsulation related to IPv4
   header construction (except for source and destination address
   determination), MTU and Fragmentation, Hop Limits and ICMP handling
   as detailed in Section 3.1-3.6 of [7].  The particular aspects of
   Configured IPv6-In-IPv4 Tunneling in the areas of IPv4 source and
   destination address determination, tunnel link characteristics and
   IPv6 Neighbor Discovery operation are not intended referred to by the
   above reference.

>> This is a very clumsy paragraph.

   This document only identifies requirements for a zero-configuration
   tunneling mechanism, based on which solutions can be developed or
   identified.

>> Also misleading - do you mean the requirements are driven by the
   available solutions??   I assume not, so it needs rewording

2.  Terminology

   Zero-Configuration Tunneling site: A logical IPv4 network over which
   IPv6 connectivity is provided to dual-stack nodes by means of
   Zero-Configuration Tunneling.

>> Seems to also be a single-provider IPv4 network?

   Tunnel End-Point (TEP): A dual-stack node performing IPv6-in-IPv4
   tunnel encapsulation/decapsulation in accordance with
   Zero-Configuration Tunneling.

>> "in accordance with zct", but zct is not defined in this section?

   Tunnel Server (TS): A dual-stack server node with IPv6 connectivity
   and which provides IPv6 connectivity to client nodes by performing
   IPv6-in-IPv4 tunnel encapsulation/decapsulation to/from client nodes
   in accordance with Zero-Configuration Tunneling.  A Tunnel Server is
   likely to be a dual-stack router.

>> "with IPv4 and IPv6 connectivity"?

   Direct Tunneling: Direct tunnelling here refer to the case where
   end-hosts located within the same Zero-Configuration Tunnelling site
   may circumvent the Tunnel Server and communicate directly using the
   tunnel protocol.

>> Somewhere in this document do we need to comment on IPv4 compatible
   addressing, which is a form of zct?   These have been deprecated, 
   but may (or may not!) be a solution to this requirement set?

3.  Applicability

   Zero-Configuration Tunneling does not attempt to provide emulation of
   the full set of native IPv6 connectivity functions as defined by [8],
   [9] and [10]

>> You're jumping into wider comments without yet saying what the zct
   should provide?   I think you should spell out what the requirements
   are first?  (Which is in Section 6, so maybe put this text there?)

   It is possible that the same zero-configuration Tunneling mechanism
   can be used in various deployment scenarios.  However, it is not
   required that same tunnel set-up protocol be deployable in all
   scenarios.

>> But we'd prefer one solution, so a node in different environments can
   use a single solution?

4.  Limitations

4.1  IPv6 address allocation, Scope and Limitations

   It is not explicitly within the scope to support privacy extensions
   to IPv6 [11].

>> Do you mean there is no requirement to support it?  If so, just say so.

   It is not explicitly within the scope to support usage of IPv6
   multicast.

>> Ditto.   (Though that is disappointing)

4.2  IPv6 tunnel link characteristics, Scope and Limitations

   Direct tunneling is neither an explicit goal nor explicitly excluded
   in Zero-Configuration Tunneling.

>> Ditto.

   It is not an explicit requirement for the zero-configuration tunnel
   link to support IPv6 link-local multicast.

>> Is that going to cause problems?  Perhaps clarify this.

   The tunnel protocol should allow for the formation of a link-local
   address on the tunnel link, though no particular usage of such an
   address is explicitly demanded by the goals set forward here.

>> Do you need the words after the ","?

5.  Basic Assumptions and Prerequistes

   Zero-configuration Tunneling is a simple mode with no user
   registration, essentially deployed in a controlled and
   "authenticated" environment where the service is made available to
   all the IPv4 customers.

>> s/essentially/typically?

   o  The user is being authenticated to the network by means external
      to the tunneling protocol.

>> But this solution can be used in open networks?  Or only authenticated 
   access ones?

   The following assumption is only valid for basic requirements where
   there is no NAT in the path.

   o  The Zero-Configuration Tunneling network is fully penetrable for
      intra-site IPv6-in-IPv4 Protocol 41 traffic.

>> Earlier you said "the tunnelling mechanism in [7]"... say that here or
   do you need to explictly specify proto-41?  (Just be consistent)

   It is a prerequisite that the tunnel protocol must work in IPv4
   network environments where IPv4 multicast is not provided.

6.  Requirements for Zero-Configuration Tunneling Mechanisms

6.1  Basic Requirements

   The basic requirements described below must be supported by any
   zero-configuration tunneling protocol.  Tunneling protocol satisfying
   these basic requirements could be used in a deployment scenarios
   which is NAT-free, does not require IPv6 /64 address or prefix
   delegation.

>> The second sentence should be broken out into explicit assumptions
   or requirements.   Do you mean there should be no NATs between the
   client and tunnel server (or must not be)?   Do you mean the requirement
   is to only support /128 tunnels?   How does prefix delegation relate
   to a node-based mechanism?

6.1.1  Simplicity

   The tunnel protocol is easy to implement in the targeted environment.
   Additionally, the protocol should provide a reasonable,limited set of
   basic IPv6 connectivity features

>> What are these "reasonable, limited" features?

6.1.2  Automated IPv6-in-IPv4 tunnel establishment

   The mechanism must be fully dynamic in the sense that it must not
   require IP address information such as the IPv4 address of a Tunnel
   Server and/or the IPv6 address(es) to use for IPv6 connectivity to be
   configured on the Tunnel Clients beforehand.

>> So you mean automatic not dynamic?   If so, state that tunnel endpoint
   discovery is required, but is out of scope of this document.

6.1.3  IPv6 Address Assignment and Prefix Delegation

   Prefix Delegation support is dealt with respect to various deployment
   scenarios in sections 6, 7, 8 and 9.  It is not however required that
   any tunneling protocol supporting only basic requirements provide
   support for prefix delegation.

>> I'm not clear why you'd want to do prefix-delegation to a node?
   Or is zct to be applied to links as well?

   It is preferable that the address assignment provides a stable
   address, that is, an address that can be used for IPv6 connectivity
   for a certain amount of time rather than solely one address per
   higher layer session initiation

>> A bit clumsy, just delete text after the ","?

>> Do you mean the same address on reconnection later?  If so, how do
   you do that without use of authentication, cookies or similar?

6.1.5  Tunnel Server End-Point Discovery

   In order to offer "plug and play", the implementation should allow a
   mechanism to discover the address of the tunnel server that will
   provide the tunnel connectivity.  This discovery should be automatic
   within a Service Provider's network.

>> Again state TEP discovery mechanism is outside the scope of this doc?
   Or is it not?  If you state it's required, a pointer to more info is
   needed.

6.1.7  Private and public IPv4 addresses

   The tunnel protocol must work over IPv4 sites deploying both private
   and public IPv4 addresses.

   Furthermore, the tunnel protocol should work with both dynamic and
   static IPv4 address allocation.

>> What does this mean, in practice?  Do you mean the zct method should
   support the IPv4 address changing while the tunnel is up??   If you
   mean to get the same IPv6 address when reconnecting on a new IPv4
   dynamic address on a new session, how do you do that without any
   authentication?

6.1.8  Scalability and Load-Balancing

   This may be achieved using load balancing functions provided by the
   Tunnel Server End-point Discovery mechanism as detailed in [13].

>> So now you add a pointer to the TEP text; this is needed earlier also.

6.1.9  Easy to deploy and Easy to Phase Out

   Once IPv6 is available natively in the access network, it should be
   easy to phase out the tunneling protocol.

>> Two subtle different meanings to "should" here... :)

6.2.1  Tunnel Link Sustainability

   In certain environments, like in 3GPP, to minimize the overhead and
   latency associated with tunnel initialisation, it is highly desirable
   that tunnels remain active for a large amount of time, ideally
   infinitely.  In such environments, the tunnel protocol must not
   mandate keep-alive messages to be transmitted by the host simply in
   order to sustain tunnel link connectivity.

>> Presumably in a no-NAT environment such keep-alives are not so
   necessary.   Some tunnel brokers use heartbeats to allow reconnection
   with the same (address) parameters.  Maybe that's beyond zct scope.

6.2.2  NAT Traversal

   The Tunnel set-up protocol must be able detect the presence of one or
   more NATs in its path.  It must be able to adapt to the following
   cases, by choosing the most optimal tunnel encapsulation depending on
   the presence of a NAT.

>> But above you said no-NAT environments?  Which is it?

>> Are you saying NAT traversal must be supported?

6.2.3  Firewall Traversal

   Even if no NAT is in the tunnel path, there may be a firewall which
   prohibits proto-41.  In such case, the tunnel encapsulation selection
   based on NAT detection will select a tunnel that will not work.

>> Doesn't that depend on the specifics of the detection mechanism?

   The implementation must allow a user to explicitly specify the
   desired tunnel encapsulation, regardless of the NAT detection
   process.

6.2.4  Extensibility

   The protocol must be extensible to support tunnel encapsulation other
   than IPv6 in IPv4 and IPv6 in transport in IPv4.  In particular,
   encapsulation of IPv4 in IPv6 or IPv6 in IPv6 could be defined.

>> "must be" or "could be" - decide :)

6.2.5  IPv6 Address Stability

   [This section shall be removed after getting more opinions from
   others.]

   The IPv6 address is "transient" and may change, but the protocol
   should offer a mechanism to provide IPv6 address stability (e.g.
   cookie mechanism).  The implementation of this mechanism must allow
   this feature to be turned off.

>> You already mentioned this earlier.  Just do it in one place?

8.  Unmanaged Networks Specific Requirements

   An unmanaged network is where no network manager or staff is
   available to configure network devices.  

>> No need to state what it is, just cite the unman-scenario text,
   which you do just below, so delete this.

   Zero-Configuration Tunneling
   Protocol is quite useful in this context where automation of IPv6
   connectivity to first-hop ISP and prefix assignment is handled.

   Unmanaged Networks [3] may or may not be behind a NAT.

   A zero-configuration tunneling mechanism should satisfy the basic
   requirements (see section 6.1) and should take into account the
   specific requirements described below.

8.1  Address Assignment and Prefix Delegation

   In unmanaged networks, assignment of an IPv6 address (/64) to the
   end-node must be supported.

>> OK, so it isn't a node-based mechanism.   Get the text at the start :)

8.2  NAT Traversal

   The implementation must provide an option to to turn on extra
   encapsulation manually.In order to assure interoperability, at least
   one common tunnel encapsulation type must be supported.

>> Are you going to name one?

8.3  Firewall Traversal

   As indicated in section 6.2.3, the tunneling protocol must be able to
   work in networks where the firewall prohibits proto-41 packets.

>> But firewalls implement policy, and won;t that policy prevent other
   types of tunnelling?

9.  Enterprise Network Requirements

   In an enterprise network where IPv4 is dominant, a tunneled
   infrastructure can be used to provider IPv6 services to the IPv6
   islands (hosts or networks) inside the enterprise, before a full IPv6
   native infrastructure is built.  Zero-Configuration tunneling
   protocol can be used to give IPv6 connectivity and prefix information
   for the islands.  This gives to the enterprise a basic deployment of
   IPv6 while maintaining automation and permanence of the IPv6
   assignments to the islands.

>> Isn't this unlikely?  Wouldn't the network administrators prefer a
   structured and managed deployment method?

   In cases where the network administrator is sure about the absence of
   internal NAT and firewalls in the network, and end-nodes will need
   only IPv6 /128 address, a tunneling protocol satisfying only the
   basic requirements will suffice.

>> And there's no need for IPv6 address stability, or extensibility in
   the network (to be consistent with 6.2)

   A zero-configuration tunneling mechanism should satisfy the basic
   requirements (see section 6.1) and should take into account the
   specific requirements described below.

>> Why are they below and not just in section 6??   The requirements
   are being repeated in the scenario sections, bloating the text.

9.4.1  IPv4-in-IPv6 Tunneling

   The tunneling Protocol should be able to handle automatic
   establishment of IPv4-in-IPv6 tunnels.  It must be able to handle
   assignment of temporary IPv4 address and other tunnel parameters as
   required.

>> This is a new one, and only suggested higher up in the doc, I
   would cite it as an advanced requirement?

10.  ISP Network Specific Requirements

   In a scenario where connection to customer from ISP supports both
   IPv4 and IPv6, but the customer has IPv6-only network and the ISP
   backbone is IPv4-only, IPv6 packets from customer needs to be
   tunneled over the IPv4 backbone to the next upstream ISP.
   Zero-configuration tunneling mechanism can be used in such scenario
   as well.

>> So it's being used for a whole network here, not a node?




From owner-v6ops@ops.ietf.org  Sun Nov  7 19:31:56 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15000
	for <v6ops-archive@lists.ietf.org>; Sun, 7 Nov 2004 19:31:56 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CQxRK-0006bC-0h
	for v6ops-data@psg.com; Mon, 08 Nov 2004 00:31:22 +0000
Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CQxRI-0006aq-9b
	for v6ops@ops.ietf.org; Mon, 08 Nov 2004 00:31:20 +0000
Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131])
	by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id iA80VJGn029059
	for <v6ops@ops.ietf.org>; Mon, 8 Nov 2004 00:31:19 GMT
Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162])
	by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id AAA29786
	for <v6ops@ops.ietf.org>; Mon, 8 Nov 2004 00:31:17 GMT
Received: (from tjc@localhost)
	by login.ecs.soton.ac.uk (8.11.6/8.11.6) id iA80VH621671
	for v6ops@ops.ietf.org; Mon, 8 Nov 2004 00:31:17 GMT
Date: Mon, 8 Nov 2004 00:31:17 +0000
From: Tim Chown <tjc@ecs.soton.ac.uk>
To: v6ops@ops.ietf.org
Subject: Comments on draft-ietf-v6ops-assisted-tunneling-requirements-01
Message-ID: <20041108003117.GI19316@login.ecs.soton.ac.uk>
Mail-Followup-To: v6ops@ops.ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4i
X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information
X-ECS-MailScanner: Found to be clean
X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-3.5 required=5.0 tests=AWL,BAYES_00,SUBJ_HAS_UNIQ_ID 
	autolearn=no version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

Hi,

Commenst on this draft are less numerous.   I think it reads better, and
is much more nicely focused.

The open question seems to be the relationship between this and ZCT, esp.
since this has identical chunks of text in places to ZCT :)


                Goals for Registered Assisted Tunneling
          draft-ietf-v6ops-assisted-tunneling-requirements-01


>> There is a lot of overlap with ZCT; should these documents be
   merged and authentication/TSP be made an extra requirement? 
   i.e. should we have one solution that has authentication/TSP
   options, or two separate solutions?  (Or does that not matter?)
   We should also be clear about the applicability to nodes and/or
   networks by ZCT and this work.

>> (there is a fair amount of text in here cut and pasted from ZCT)

1.  Goal and Scope of the Document


   "Assisted tunneling" is used in this document to describe a
   transition mechanism where the parameters to configure a
   bi-directional tunnel between an end-node (or leaf network) and a
   router in the core of an ISP are exchanged through a tunnel set-up
   protocol.  Although this exchange can be automated, this remains
   different from transition mechanisms like 6to4, Teredo or ISATAP.  In
   particular, assisted tunneling enables explicit access control to the
   tunneled IPv6 connectivity, where the other transion mechanisms have
   to rely on other kinds of control (e.g., access control based on the
   IPv4 address).  Also, assisted tunneling protocol negotiate the
   tunnel parameters and does not depend on having the IPv4 address
   inside the IPv6 address, for example.

>> It should be clearer what the difference between this draft and the
   ZCT draft is.  From the intro text, it seems to be the use of a 
   tunnel setup protocol, and thus the possibility of authentication
   of users.

>> As per ZCT, does this draft apply to nodes or networks too?


2.  Applicability

   o  The customer configuration may be diverse, and not necessarily
      predictable by the ISP.  The protocol must be able to adapt to the
      following cases, for example by choosing the most optimal tunnel
      encapsulation depending on the presence of a NAT.

      *  a single node,
      *  a leaf network,
      *  using a globally routable IPv4 address,
      *  behind a NAT (customer or ISP owned),
      *  using dynamic IPv4 address (internally or externally to the
         NAT)

>> So it is nodes and networks.  I think that's good for assisted
   tunnelling, but ZCT should probably be nodes only?   Is this a
   distinction to draw (assuming we keep the texts separate)?

>> The NAT and dynamic IPv4 address support should be requirements?

   There are actually two cases where the IPv4 address of the customer
   tunnel end point can be dynamic, and both must be supported:

   o  The device used as tunnel end point is using a dynamic IPv4
      address provided by the ISP.

   o  The device used as tunnel end point is located behind a customer
      owned NAT box that is also acting as a local DHCP server.  In that
      case, the device IPv4 address may change after a reboot.

>> This text is copied from the ZCT draft... how much else is copied?
   (Just curious)

   In the enterprise scenario [I-D.ietf-v6ops-ent-analysis], assisted
   tunneling can be used to support remote users connecting to the
   enterprise network (section 7.5.2).

>> Or to connect IPv6 islands inside the network?  (I'm not convinced
   it should be, but it could be)

3.  Requirements for Simplicity

   This protocol is a transition mechanism, thus does not need to be
   perfect.  As a matter of fact, making it perfect would be counter
   productive, at it would first delay its definition, then make its
   deployment more cumbersome and, last but not least, diminish the
   incentives to deploy native IPv6.

>> I think this paragraph should be deleted.

4.  Protocol Requirements

   o  stay in touch with users

>> And per-user accounting? (and users might like to see their v6 usage     
   too?)

4.4  Confidentiality

   Protecting the tunneled data (IPv6 in this case) should be possible.
   A possible usage scenario is when an enterprise's users is working
   off-site and tunneling to the enterprise network (7.5.2
   [I-D.ietf-v6ops-ent-analysis]).  Mechanisms do exist to make this
   possible, such as using IPsec over IPv6 [RFC2401].
   [I-D.tschofenig-v6ops-secure-tunnels] may be applicable here but is
   not analysed further.

>> Users may also VPN home with v4 and then tunnel; this kind of 
   approach is being used (e.g. with OpenVPN).   It's an interesting
   question as to which approach is "better".

4.5  Service Discovery

   In order to facilitate deployment, the implementation should allow a
   mechanism to discover the address of the server that will provide the
   tunnel connectivity.

   This discovery should be automatic when the protocol is used within
   an ISP network.  There is no service discovery requirements when used
   outside the provider network (roaming users, 3rd party ISP).

>> But if I'm at the IETF, outside my university/ISP network, I really do
   want to discover a tunnel end point automatically...?

   Tunnel end-point discovery mechanism work
   ([I-D.palet-v6ops-tun-auto-disc] may be applicable here.

>> You mean "is" not "may be"?

4.6  NAT Traversal

   NAT traversal is identified as a requirement in ISP scenarios
   (section 5.1 [I-D.ietf-v6ops-isp-scenarios-analysis]) and unmanaged
   scanarios (section 7, Recommendation 1 [RFC3904])

4.7  Firewall Traversal

   Even if no NAT is in the tunnel path, there may be a firewall which
   prohibits IP protocol 41.  In such case, the tunnel encapsulation
   selection based on NAT detection (Section 5.2) will select a tunnel
   that will not work.

>> Another example of text cut and pasted from ZCT...

5.7  Extensibility

   The protocol must be extensible to support tunnel encapsulation other
   than IPv6 over IPv4 and IPv6 over transport over IPv4.  In
   particular, encapsulation of IPv4 over IPv6 (section 7
   [I-D.ietf-v6ops-isp-scenarios-analysis], section 7 [RFC3904], section
   6 [I-D.ietf-v6ops-ent-analysis]) or IPv6 over IPv6 could be defined.

>> The "must" is strong, but I would agree with it, if we want a 
   single mechanism to be applicable in the longer term.  But this is
   likely to be contentious... :)

6.  Compatibility with other Transition Mechanisms

   The tunnel set-up protocol is not required to be compatible with any
   existing transition mechanism.  Although, a great deal of experience
   can be drawn from the operation of tunnel brokers currently using the
   TSP protocol [I-D.blanchet-v6ops-tunnelbroker-tsp].

>> But are various TSPs compatible / interoperable with each other?




From owner-v6ops@ops.ietf.org  Sun Nov  7 19:49:58 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16934
	for <v6ops-archive@lists.ietf.org>; Sun, 7 Nov 2004 19:49:57 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CQxif-00095n-EE
	for v6ops-data@psg.com; Mon, 08 Nov 2004 00:49:17 +0000
Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CQxie-00095R-Bw
	for v6ops@ops.ietf.org; Mon, 08 Nov 2004 00:49:16 +0000
Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131])
	by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id iA80nFGn029522
	for <v6ops@ops.ietf.org>; Mon, 8 Nov 2004 00:49:15 GMT
Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162])
	by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id AAA29825
	for <v6ops@ops.ietf.org>; Mon, 8 Nov 2004 00:49:14 GMT
Received: (from tjc@localhost)
	by login.ecs.soton.ac.uk (8.11.6/8.11.6) id iA80nEq21985
	for v6ops@ops.ietf.org; Mon, 8 Nov 2004 00:49:14 GMT
Date: Mon, 8 Nov 2004 00:49:14 +0000
From: Tim Chown <tjc@ecs.soton.ac.uk>
To: v6ops@ops.ietf.org
Subject: Comments on draft-nielsen-v6ops-3GPP-zeroconf-goals-00
Message-ID: <20041108004913.GJ19316@login.ecs.soton.ac.uk>
Mail-Followup-To: v6ops@ops.ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4i
X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information
X-ECS-MailScanner: Found to be clean
X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

Hi,

I started reading draft-nielsen-v6ops-3GPP-zeroconf-goals-00, but I'm
not clear why we need this text rather than just reading
draft-suryanarayanan-v6ops-zeroconf-reqs-00 for the 3GPP part?

(In theory, draft-suryanarayanan-v6ops-zeroconf-reqs-00 could/should
list all the requirements, and each of the 4 scenario sections - 3gpp,
isp, unman, enterprise - should point at which requirements they carry?)

Will we thus see more simialr docs for unman, ent and isp?  

I'm confused :)

Tim



From owner-v6ops@ops.ietf.org  Sun Nov  7 20:47:52 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21821
	for <v6ops-archive@lists.ietf.org>; Sun, 7 Nov 2004 20:47:51 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CQycD-000GyV-23
	for v6ops-data@psg.com; Mon, 08 Nov 2004 01:46:41 +0000
Received: from [193.180.251.53] (helo=eagle.ericsson.se)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CQycB-000GyF-S0
	for v6ops@ops.ietf.org; Mon, 08 Nov 2004 01:46:40 +0000
Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120])
	by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id iA81kcR2018227
	for <v6ops@ops.ietf.org>; Mon, 8 Nov 2004 02:46:39 +0100
Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211);
	 Mon, 8 Nov 2004 02:46:38 +0100
Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id WB150PBP; Mon, 8 Nov 2004 02:46:38 +0100
Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <VJQGN21T>; Mon, 8 Nov 2004 02:46:38 +0100
Message-ID: <C26BB8276599A44B85D52F9CE41035E1050B980E@esealnt944.al.sw.ericsson.se>
X-Sybari-Trust: a4729086 8cefd49f 19e455e7 00000138
From: "Karen E. Nielsen (AH/LMD)" <karen.e.nielsen@ericsson.com>
To: "'Tim Chown'" <tjc@ecs.soton.ac.uk>, v6ops@ops.ietf.org
Subject: RE: Comments on draft-nielsen-v6ops-3GPP-zeroconf-goals-00
Date: Mon, 8 Nov 2004 02:46:37 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
X-OriginalArrivalTime: 08 Nov 2004 01:46:38.0813 (UTC) FILETIME=[C9D160D0:01C4C534]
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

Hi Tim,

The 3gpp draft could have been a separate chapter of 
draft-suryanarayanan-v6ops-zeroconf-reqs-00.

I think it has been explained in length on the list why it isn't, but let
me do it once more:

"Procedural":
There's a certain urgency to solve the 3gpp case and as the 3gpp
requirements, spelled out in the previous version of
this document, was thought to be in a mature state it was judged
best to keep this separate to avoid 
the delay and the "blur" that could arise from integrating this into
the generic zeroconf document.

As you point out in a different mail - then it is difficult to keep track of
the generic requirements from the environment specific ones in the generic 
zeroconf document.

Technical:
The constrained conditions of 3gpp: bandwidth, round trips times (and costs)
singles out the 3gpp environment compared to the other cases considered. 

These conditions may have implications that are in conflict with some of the 
requirements for advanced features of the other scenarios. 

Something else:
Having said this, it has been pointed out by many that given that the 3gpp document
is indeed about 3gpp only, some "generic" zeroconf text should be removed
and furthermore more text should be added on the explicit 3gpp deployment scenario.

BR, Karen

> -----Original Message-----
> From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On
> Behalf Of Tim Chown
> Sent: Monday, November 08, 2004 1:49 AM
> To: v6ops@ops.ietf.org
> Subject: Comments on draft-nielsen-v6ops-3GPP-zeroconf-goals-00
> 
> 
> Hi,
> 
> I started reading draft-nielsen-v6ops-3GPP-zeroconf-goals-00, but I'm
> not clear why we need this text rather than just reading
> draft-suryanarayanan-v6ops-zeroconf-reqs-00 for the 3GPP part?
> 
> (In theory, draft-suryanarayanan-v6ops-zeroconf-reqs-00 could/should
> list all the requirements, and each of the 4 scenario sections - 3gpp,
> isp, unman, enterprise - should point at which requirements 
> they carry?)
> 
> Will we thus see more simialr docs for unman, ent and isp?  
> 
> I'm confused :)
> 
> Tim
> 



From owner-v6ops@ops.ietf.org  Sun Nov  7 21:14:31 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23306
	for <v6ops-archive@lists.ietf.org>; Sun, 7 Nov 2004 21:14:31 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CQz2A-000L3n-15
	for v6ops-data@psg.com; Mon, 08 Nov 2004 02:13:30 +0000
Received: from [213.172.48.142] (helo=consulintel.es)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CQz28-000L1T-Ev
	for v6ops@ops.ietf.org; Mon, 08 Nov 2004 02:13:28 +0000
Received: from [130.129.135.232] ([130.129.135.232])
	by consulintel.es (consulintel.es [127.0.0.1])
	(MDaemon.PRO.v7.2.0.R)
	with ESMTP id md50000565063.msg
	for <v6ops@ops.ietf.org>; Mon, 08 Nov 2004 03:18:57 +0100
User-Agent: Microsoft-Entourage/10.1.4.030702.0
Date: Sun, 07 Nov 2004 21:07:41 -0500
Subject: Re: other comments on draft-nielsen-v6ops-3GPP-zeroconf-goals-00.
	txt
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: <v6ops@ops.ietf.org>
Message-ID: <BDB43F1D.4E843%jordi.palet@consulintel.es>
In-Reply-To: <C26BB8276599A44B85D52F9CE41035E1050B9809@esealnt944.al.sw.ericsson.se>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Spam-Processed: consulintel.es, Mon, 08 Nov 2004 03:18:57 +0100
	(not processed: message from valid local sender)
X-MDRemoteIP: 130.129.135.232
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ops.ietf.org
Reply-To: jordi.palet@consulintel.es
X-MDAV-Processed: consulintel.es, Mon, 08 Nov 2004 03:18:59 +0100
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Karen,

Yes, when tun-auto-disc was published, the other one was still not
available. We could mention it in the next version, no problem on that.



Regards,
Jordi


> De: "Karen E. Nielsen (AH/LMD)" <karen.e.nielsen@ericsson.com>
> Responder a: owner-v6ops@ops.ietf.org
> Fecha: Sun, 7 Nov 2004 22:11:48 +0100
> Para: "'Alain.Durand@Sun.COM'" <Alain.Durand@Sun.COM>, Pekka Savola
> <pekkas@netcore.fi>
> CC: "'''IPv6 Operations ' ' '" <v6ops@ops.ietf.org>
> Asunto: RE: other comments on draft-nielsen-v6ops-3GPP-zeroconf-goals-00. txt
> 
> Alain, Pekka, Jordi
> 
> I am fine with not referencing the NAPTR draft.
> 
> My original reasoning for referencing it was indeed that it wasn't referenced
> in draft-palet-v6ops-tun-auto-disc-00.txt.
> 
> Thinking more on this issue on the way here, I actually have an additional
> reason for not wanting to explicitly reference this particular solution in
> the 3gpp-zeroconf draft at this stage in time.
> 
> The reason is that whereas for example the prefix'ed DNS search path approach
> analysed in
> draft-palet-v6ops-tun-auto-disc-00.txt may be a good fit for the 3gpp
> environment, then
> the more general NAPTR solution is less optimal from the 3gpp environment
> perspective
> as it would require one additional RT compared to the 1 RT required by the
> prefix'ed DNS search path approach
> - this as one in the 3gpp environment possibly may assume that the end-user
> knows the Ipv4 domain name.
> 
> Now, I am not trying to say that the NAPTR cannot turn out to be the unified
> solution for 
> server discovery - provided that we are going to have one unified solution,
> that is - but as
> it doesn't seem to be the most optimal approach for the 3gpp environment, it
> would
> be even more wrong to single it out as a solution in this document, I think.
> 
> BR, Karen
> 
> 
>> -----Original Message-----
>> From: Alain.Durand@Sun.COM [mailto:Alain.Durand@Sun.COM]
>> Sent: Friday, November 05, 2004 6:31 PM
>> To: Pekka Savola
>> Cc: Karen E. Nielsen (AH/LMD); '''IPv6 Operations ' ' '
>> Subject: Re: other comments on
>> draft-nielsen-v6ops-3GPP-zeroconf-goals-00. txt
>> 
>> 
>> Pekka Savola wrote:
>> 
>>> One comment on a comment,
>>> 
>>> On Fri, 5 Nov 2004, Karen E. Nielsen (AH/LMD) wrote:
>>> 
>>>>> Tunnel end-point discovery
>>>>> -------------------------------------
>>>>> This document should also reference
>>>>> http://www.ietf.org/internet-drafts/draft-yamamoto-naptr-service-
>>>>> discovery-00.txt
>>>>> 
>>>> 
>>>> Yes, now it should. Thanks.
>>>> 
>>>> Let me and the other authors think about how it should be put
>>>> exactly, I have a small concern with this in the 3gpp
>> environment due 
>>>> to RT delays (more or that to come).
>>> 
>>> 
>>> Let me disagree here, rather strongly.
>>> 
>>> The requirements document like this should not point at various
>>> solutions documents.  In the case of tunnel endpoint discovery, we
>>> have a good document
>> (draft-palet-v6ops-tun-auto-disc-00.txt) -- which
>>> could include more discussion relating to draft-yamamoto-,
>> but there 
>>> is no need to refer to that *HERE*.
>> 
>> We might be in violent agreement. My point is that either the
>> requirement specs reference
>> all possible solutions or none and stick to requirements.
>> Referencing only one potential solution is wrong.
>> That said, I agree that all the tunnel end point discovery solutions
>> should be merged.
>> 
>>     - Alain.
>> 
> 
> 



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






From owner-v6ops@ops.ietf.org  Sun Nov  7 22:49:43 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01578
	for <v6ops-archive@lists.ietf.org>; Sun, 7 Nov 2004 22:49:43 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CR0Vb-0007wV-7J
	for v6ops-data@psg.com; Mon, 08 Nov 2004 03:47:59 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CR0Va-0007wG-3B
	for v6ops@ops.ietf.org; Mon, 08 Nov 2004 03:47:58 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id iA83lu231237
	for <v6ops@ops.ietf.org>; Mon, 8 Nov 2004 05:47:56 +0200
Date: Mon, 8 Nov 2004 05:47:56 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: v6ops@ops.ietf.org
Subject: v6ops WG document status
Message-ID: <Pine.LNX.4.61.0411080535590.31062@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

Hi,

(co-chair hat on)

In order to make the meeting go quicker, here's the status of v6ops WG 
documents.  Please read and send your comments / questions now.

......

Still in the WG
===============

draft-ietf-v6ops-ent-analysis 
draft-ietf-v6ops-assisted-tunneling-requirements
 	(+ other tunneling reqs documents)
  ==> both to be discussed at this meeting

Forwarded for publication
=========================

draft-ietf-v6ops-onlinkassumption
  ==> waiting for rfc2461bis to be (reasonably) complete, now at IPv6 
WGLC

draft-ietf-v6ops-v6onbydefault
  ==> waiting for the fixes (most notably, TCP behaviour change) to 
complete; alternative resolution: publish a less useful document 
without fixes immediately

draft-ietf-v6ops-3gpp-analysis
  ==> finally agreement on IMS text, should be done after a revision

draft-ietf-v6ops-mech-v2
  ==> waiting for information from Steve Bellovin whether he requires 
us to publish v6-in-v4 IPsec document before this can be published, 
otherwise done modulo an RFC-editor removing the sentence on TTL=255.

draft-ietf-v6ops-renumbering-procedure
  ==> waiting for authors to revise to address IESG feedback (since 3 
months)

Accepted for publication, done
==============================

draft-ietf-v6ops-6to4-security
draft-ietf-v6ops-application-transition
draft-ietf-v6ops-ent-scenarios
draft-ietf-v6ops-isp-scenarios-analysis

Published since the last meeting
================================

draft-ietf-v6ops-unmaneval  as RFC3904



From owner-v6ops@ops.ietf.org  Sun Nov  7 23:13:04 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03128
	for <v6ops-archive@lists.ietf.org>; Sun, 7 Nov 2004 23:13:03 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CR0tO-000BC8-SB
	for v6ops-data@psg.com; Mon, 08 Nov 2004 04:12:34 +0000
Received: from [192.18.98.36] (helo=brmea-mail-4.sun.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CR0tO-000BBu-1P
	for v6ops@ops.ietf.org; Mon, 08 Nov 2004 04:12:34 +0000
Received: from esunmail ([129.147.156.34])
	by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id iA84CXNH027063
	for <v6ops@ops.ietf.org>; Sun, 7 Nov 2004 21:12:33 -0700 (MST)
Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM
 (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTP id <0I6U00887ECXKQ@edgemail1.Central.Sun.COM> for
 v6ops@ops.ietf.org; Sun, 07 Nov 2004 21:12:33 -0700 (MST)
Received: from [130.129.134.64] by mail.sun.net
 (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I6U0088FECVGC@mail.sun.net> for v6ops@ops.ietf.org; Sun,
 07 Nov 2004 21:12:33 -0700 (MST)
Date: Sun, 07 Nov 2004 20:14:13 -0800
From: Alain Durand <Alain.Durand@Sun.COM>
Subject: Re: other comments on draft-nielsen-v6ops-3GPP-zeroconf-goals-00.  txt
In-reply-to: 
 <C26BB8276599A44B85D52F9CE41035E1050B9809@esealnt944.al.sw.ericsson.se>
To: "Karen E. Nielsen (AH/LMD)" <karen.e.nielsen@ericsson.com>
Cc: Pekka Savola <pekkas@netcore.fi>,
        "'''IPv6 Operations ' ' '" <v6ops@ops.ietf.org>
Message-id: <418EF295.6080408@sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20040906
References: 
 <C26BB8276599A44B85D52F9CE41035E1050B9809@esealnt944.al.sw.ericsson.se>
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7BIT

Karen E. Nielsen (AH/LMD) wrote:

>The reason is that whereas for example the prefix'ed DNS search path approach analysed in
>draft-palet-v6ops-tun-auto-disc-00.txt may be a good fit for the 3gpp environment, then
>the more general NAPTR solution is less optimal from the 3gpp environment perspective
>as it would require one additional RT compared to the 1 RT required by the prefix'ed DNS search path approach 
>  
>
You can use only one RT with the NAPTR solution using the additional 
section data.

    - Alain.




From owner-v6ops@ops.ietf.org  Mon Nov  8 00:47:11 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09389
	for <v6ops-archive@lists.ietf.org>; Mon, 8 Nov 2004 00:47:11 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CR2LI-000KCx-Qg
	for v6ops-data@psg.com; Mon, 08 Nov 2004 05:45:28 +0000
Received: from [203.254.224.33] (helo=mailout3.samsung.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CR2LG-000KC2-Kx
	for v6ops@ops.ietf.org; Mon, 08 Nov 2004 05:45:27 +0000
Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com
 (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003))
 id <0I6U009GZINO7U@mailout3.samsung.com> for v6ops@ops.ietf.org; Mon,
 08 Nov 2004 14:45:24 +0900 (KST)
Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33])
 by mailout3.samsung.com
 (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003))
 with ESMTP id <0I6U0004SIHFEZ@mailout3.samsung.com> for v6ops@ops.ietf.org;
 Mon, 08 Nov 2004 14:41:39 +0900 (KST)
Received: from Radhakrishnan ([107.108.71.58])
 by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23
 2003)) with ESMTPA id <0I6U00EUUIHD8O@mmp2.samsung.com> for
 v6ops@ops.ietf.org; Mon, 08 Nov 2004 14:41:39 +0900 (KST)
Date: Mon, 08 Nov 2004 11:07:30 +0530
From: Radhakrishnan Suryanarayanan <rkrishnan.s@samsung.com>
Subject: Re: Comments on draft-suryanarayanan-v6ops-zeroconf-reqs-00
To: Tim Chown <tjc@ecs.soton.ac.uk>, v6ops@ops.ietf.org
Reply-to: Radhakrishnan Suryanarayanan <rkrishnan.s@samsung.com>
Message-id: <00d901c4c555$51645b40$3a476c6b@sisodomain.com>
Organization: SAMSUNG India Software Operations
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <20041107234837.GH19316@login.ecs.soton.ac.uk>
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7BIT

Hi Tim,
 Thanks a lot for your comments.
 I will reply to your comments in detail ASAP. In the meantime, may i
request you to look into the revision 01 for the draft

http://www.v6ops.euro6ix.net/ietf/draft-suryanarayanan-v6ops-zeroconf-reqs-01.txt

This draft is derived from non-registered mode discussed in the previous
assisted tunneling requirements and partly from 3gpp-specific ZCT. Hence
those identical chunks of text in places.

A reason for putting requirements under the scenario-specific is because of
the need in some places
related to making some of the requirements "must" or "should" from "should"
or "may".

Nevertheless, there is lot of scope to improve the document and i shall try
my best to do it. :)

>(In theory, draft-suryanarayanan-v6ops-zeroconf-reqs-00 could/should
>list all the requirements, and each of the 4 scenario sections - 3gpp,
>isp, unman, enterprise - should point at which requirements they carry?)
Ideally a single draft should be sufficient.:)

>Will we thus see more simialr docs for unman, ent and isp?
Definitely NOT. 3GPP is just one off case because of its timing
requirements.

Thanks & Regards
Radhakrishnan
----- Original Message ----- 
From: "Tim Chown" <tjc@ecs.soton.ac.uk>
To: <v6ops@ops.ietf.org>
Sent: Monday, November 08, 2004 5:18 AM
Subject: Comments on draft-suryanarayanan-v6ops-zeroconf-reqs-00


> Hi,
>
> Some comments on this draft.   Overall I found it seemed overly long,
> it meandered somewhat and lacked some focus, and included a number of
> repeated chunks of text that could be saod in one place.
>
>
>                Zero-Configuration Tunneling Requirements
>             draft-suryanarayanan-v6ops-zeroconf-reqs-00.txt
>
>
> >> Main comments:
>
> >> 1. Not clear what scope is, e.g. single node or not, within the
>       network of a single provider or not, is host-host zct supported
>       or not, etc.
>
> >> 2. Should state assumptions in one place/section, they are split
>       across the document in many places.  This would include the
>       two items in the "out of scope" appendix.
>
> >> 3. Should list all requirements in one section and have the four
>       scenarios refer to that, at present some scenarios have their
>       own (sometimes repeated) requirements.
>
> >> Specific comments:
>
> 1.  Introduction
>
>    One of the major differences between the zero-configuration tunneling
>    mechanism and the full-fledged tunneling mechanism is that the former
>    does not support user authentication, which should not be an issue
>    because the scope of the users of this mechanism are already users of
>    the Service Provider actually deploying it.  Consequently, the users
>    are to be authenticated by other means, which are out of the scope of
>    this document.
>
> >> Thus this zct solution is only for intra-provider solutions?  Just
>    state that if it's the case.
>
> >> Is this a solution for single nodes only?  If so, state that clearly
>    early on.
>
>    It should be emphasized that unless otherwise specified, in this
>    document the reference, IPv6-in-IPv4 encapsulation as defined in [7],
>    refers to the aspects of Protocol-41 encapsulation related to IPv4
>    header construction (except for source and destination address
>    determination), MTU and Fragmentation, Hop Limits and ICMP handling
>    as detailed in Section 3.1-3.6 of [7].  The particular aspects of
>    Configured IPv6-In-IPv4 Tunneling in the areas of IPv4 source and
>    destination address determination, tunnel link characteristics and
>    IPv6 Neighbor Discovery operation are not intended referred to by the
>    above reference.
>
> >> This is a very clumsy paragraph.
>
>    This document only identifies requirements for a zero-configuration
>    tunneling mechanism, based on which solutions can be developed or
>    identified.
>
> >> Also misleading - do you mean the requirements are driven by the
>    available solutions??   I assume not, so it needs rewording
>
> 2.  Terminology
>
>    Zero-Configuration Tunneling site: A logical IPv4 network over which
>    IPv6 connectivity is provided to dual-stack nodes by means of
>    Zero-Configuration Tunneling.
>
> >> Seems to also be a single-provider IPv4 network?
>
>    Tunnel End-Point (TEP): A dual-stack node performing IPv6-in-IPv4
>    tunnel encapsulation/decapsulation in accordance with
>    Zero-Configuration Tunneling.
>
> >> "in accordance with zct", but zct is not defined in this section?
>
>    Tunnel Server (TS): A dual-stack server node with IPv6 connectivity
>    and which provides IPv6 connectivity to client nodes by performing
>    IPv6-in-IPv4 tunnel encapsulation/decapsulation to/from client nodes
>    in accordance with Zero-Configuration Tunneling.  A Tunnel Server is
>    likely to be a dual-stack router.
>
> >> "with IPv4 and IPv6 connectivity"?
>
>    Direct Tunneling: Direct tunnelling here refer to the case where
>    end-hosts located within the same Zero-Configuration Tunnelling site
>    may circumvent the Tunnel Server and communicate directly using the
>    tunnel protocol.
>
> >> Somewhere in this document do we need to comment on IPv4 compatible
>    addressing, which is a form of zct?   These have been deprecated,
>    but may (or may not!) be a solution to this requirement set?
>
> 3.  Applicability
>
>    Zero-Configuration Tunneling does not attempt to provide emulation of
>    the full set of native IPv6 connectivity functions as defined by [8],
>    [9] and [10]
>
> >> You're jumping into wider comments without yet saying what the zct
>    should provide?   I think you should spell out what the requirements
>    are first?  (Which is in Section 6, so maybe put this text there?)
>
>    It is possible that the same zero-configuration Tunneling mechanism
>    can be used in various deployment scenarios.  However, it is not
>    required that same tunnel set-up protocol be deployable in all
>    scenarios.
>
> >> But we'd prefer one solution, so a node in different environments can
>    use a single solution?
>
> 4.  Limitations
>
> 4.1  IPv6 address allocation, Scope and Limitations
>
>    It is not explicitly within the scope to support privacy extensions
>    to IPv6 [11].
>
> >> Do you mean there is no requirement to support it?  If so, just say so.
>
>    It is not explicitly within the scope to support usage of IPv6
>    multicast.
>
> >> Ditto.   (Though that is disappointing)
>
> 4.2  IPv6 tunnel link characteristics, Scope and Limitations
>
>    Direct tunneling is neither an explicit goal nor explicitly excluded
>    in Zero-Configuration Tunneling.
>
> >> Ditto.
>
>    It is not an explicit requirement for the zero-configuration tunnel
>    link to support IPv6 link-local multicast.
>
> >> Is that going to cause problems?  Perhaps clarify this.
>
>    The tunnel protocol should allow for the formation of a link-local
>    address on the tunnel link, though no particular usage of such an
>    address is explicitly demanded by the goals set forward here.
>
> >> Do you need the words after the ","?
>
> 5.  Basic Assumptions and Prerequistes
>
>    Zero-configuration Tunneling is a simple mode with no user
>    registration, essentially deployed in a controlled and
>    "authenticated" environment where the service is made available to
>    all the IPv4 customers.
>
> >> s/essentially/typically?
>
>    o  The user is being authenticated to the network by means external
>       to the tunneling protocol.
>
> >> But this solution can be used in open networks?  Or only authenticated
>    access ones?
>
>    The following assumption is only valid for basic requirements where
>    there is no NAT in the path.
>
>    o  The Zero-Configuration Tunneling network is fully penetrable for
>       intra-site IPv6-in-IPv4 Protocol 41 traffic.
>
> >> Earlier you said "the tunnelling mechanism in [7]"... say that here or
>    do you need to explictly specify proto-41?  (Just be consistent)
>
>    It is a prerequisite that the tunnel protocol must work in IPv4
>    network environments where IPv4 multicast is not provided.
>
> 6.  Requirements for Zero-Configuration Tunneling Mechanisms
>
> 6.1  Basic Requirements
>
>    The basic requirements described below must be supported by any
>    zero-configuration tunneling protocol.  Tunneling protocol satisfying
>    these basic requirements could be used in a deployment scenarios
>    which is NAT-free, does not require IPv6 /64 address or prefix
>    delegation.
>
> >> The second sentence should be broken out into explicit assumptions
>    or requirements.   Do you mean there should be no NATs between the
>    client and tunnel server (or must not be)?   Do you mean the
requirement
>    is to only support /128 tunnels?   How does prefix delegation relate
>    to a node-based mechanism?
>
> 6.1.1  Simplicity
>
>    The tunnel protocol is easy to implement in the targeted environment.
>    Additionally, the protocol should provide a reasonable,limited set of
>    basic IPv6 connectivity features
>
> >> What are these "reasonable, limited" features?
>
> 6.1.2  Automated IPv6-in-IPv4 tunnel establishment
>
>    The mechanism must be fully dynamic in the sense that it must not
>    require IP address information such as the IPv4 address of a Tunnel
>    Server and/or the IPv6 address(es) to use for IPv6 connectivity to be
>    configured on the Tunnel Clients beforehand.
>
> >> So you mean automatic not dynamic?   If so, state that tunnel endpoint
>    discovery is required, but is out of scope of this document.
>
> 6.1.3  IPv6 Address Assignment and Prefix Delegation
>
>    Prefix Delegation support is dealt with respect to various deployment
>    scenarios in sections 6, 7, 8 and 9.  It is not however required that
>    any tunneling protocol supporting only basic requirements provide
>    support for prefix delegation.
>
> >> I'm not clear why you'd want to do prefix-delegation to a node?
>    Or is zct to be applied to links as well?
>
>    It is preferable that the address assignment provides a stable
>    address, that is, an address that can be used for IPv6 connectivity
>    for a certain amount of time rather than solely one address per
>    higher layer session initiation
>
> >> A bit clumsy, just delete text after the ","?
>
> >> Do you mean the same address on reconnection later?  If so, how do
>    you do that without use of authentication, cookies or similar?
>
> 6.1.5  Tunnel Server End-Point Discovery
>
>    In order to offer "plug and play", the implementation should allow a
>    mechanism to discover the address of the tunnel server that will
>    provide the tunnel connectivity.  This discovery should be automatic
>    within a Service Provider's network.
>
> >> Again state TEP discovery mechanism is outside the scope of this doc?
>    Or is it not?  If you state it's required, a pointer to more info is
>    needed.
>
> 6.1.7  Private and public IPv4 addresses
>
>    The tunnel protocol must work over IPv4 sites deploying both private
>    and public IPv4 addresses.
>
>    Furthermore, the tunnel protocol should work with both dynamic and
>    static IPv4 address allocation.
>
> >> What does this mean, in practice?  Do you mean the zct method should
>    support the IPv4 address changing while the tunnel is up??   If you
>    mean to get the same IPv6 address when reconnecting on a new IPv4
>    dynamic address on a new session, how do you do that without any
>    authentication?
>
> 6.1.8  Scalability and Load-Balancing
>
>    This may be achieved using load balancing functions provided by the
>    Tunnel Server End-point Discovery mechanism as detailed in [13].
>
> >> So now you add a pointer to the TEP text; this is needed earlier also.
>
> 6.1.9  Easy to deploy and Easy to Phase Out
>
>    Once IPv6 is available natively in the access network, it should be
>    easy to phase out the tunneling protocol.
>
> >> Two subtle different meanings to "should" here... :)
>
> 6.2.1  Tunnel Link Sustainability
>
>    In certain environments, like in 3GPP, to minimize the overhead and
>    latency associated with tunnel initialisation, it is highly desirable
>    that tunnels remain active for a large amount of time, ideally
>    infinitely.  In such environments, the tunnel protocol must not
>    mandate keep-alive messages to be transmitted by the host simply in
>    order to sustain tunnel link connectivity.
>
> >> Presumably in a no-NAT environment such keep-alives are not so
>    necessary.   Some tunnel brokers use heartbeats to allow reconnection
>    with the same (address) parameters.  Maybe that's beyond zct scope.
>
> 6.2.2  NAT Traversal
>
>    The Tunnel set-up protocol must be able detect the presence of one or
>    more NATs in its path.  It must be able to adapt to the following
>    cases, by choosing the most optimal tunnel encapsulation depending on
>    the presence of a NAT.
>
> >> But above you said no-NAT environments?  Which is it?
>
> >> Are you saying NAT traversal must be supported?
>
> 6.2.3  Firewall Traversal
>
>    Even if no NAT is in the tunnel path, there may be a firewall which
>    prohibits proto-41.  In such case, the tunnel encapsulation selection
>    based on NAT detection will select a tunnel that will not work.
>
> >> Doesn't that depend on the specifics of the detection mechanism?
>
>    The implementation must allow a user to explicitly specify the
>    desired tunnel encapsulation, regardless of the NAT detection
>    process.
>
> 6.2.4  Extensibility
>
>    The protocol must be extensible to support tunnel encapsulation other
>    than IPv6 in IPv4 and IPv6 in transport in IPv4.  In particular,
>    encapsulation of IPv4 in IPv6 or IPv6 in IPv6 could be defined.
>
> >> "must be" or "could be" - decide :)
>
> 6.2.5  IPv6 Address Stability
>
>    [This section shall be removed after getting more opinions from
>    others.]
>
>    The IPv6 address is "transient" and may change, but the protocol
>    should offer a mechanism to provide IPv6 address stability (e.g.
>    cookie mechanism).  The implementation of this mechanism must allow
>    this feature to be turned off.
>
> >> You already mentioned this earlier.  Just do it in one place?
>
> 8.  Unmanaged Networks Specific Requirements
>
>    An unmanaged network is where no network manager or staff is
>    available to configure network devices.
>
> >> No need to state what it is, just cite the unman-scenario text,
>    which you do just below, so delete this.
>
>    Zero-Configuration Tunneling
>    Protocol is quite useful in this context where automation of IPv6
>    connectivity to first-hop ISP and prefix assignment is handled.
>
>    Unmanaged Networks [3] may or may not be behind a NAT.
>
>    A zero-configuration tunneling mechanism should satisfy the basic
>    requirements (see section 6.1) and should take into account the
>    specific requirements described below.
>
> 8.1  Address Assignment and Prefix Delegation
>
>    In unmanaged networks, assignment of an IPv6 address (/64) to the
>    end-node must be supported.
>
> >> OK, so it isn't a node-based mechanism.   Get the text at the start :)
>
> 8.2  NAT Traversal
>
>    The implementation must provide an option to to turn on extra
>    encapsulation manually.In order to assure interoperability, at least
>    one common tunnel encapsulation type must be supported.
>
> >> Are you going to name one?
>
> 8.3  Firewall Traversal
>
>    As indicated in section 6.2.3, the tunneling protocol must be able to
>    work in networks where the firewall prohibits proto-41 packets.
>
> >> But firewalls implement policy, and won;t that policy prevent other
>    types of tunnelling?
>
> 9.  Enterprise Network Requirements
>
>    In an enterprise network where IPv4 is dominant, a tunneled
>    infrastructure can be used to provider IPv6 services to the IPv6
>    islands (hosts or networks) inside the enterprise, before a full IPv6
>    native infrastructure is built.  Zero-Configuration tunneling
>    protocol can be used to give IPv6 connectivity and prefix information
>    for the islands.  This gives to the enterprise a basic deployment of
>    IPv6 while maintaining automation and permanence of the IPv6
>    assignments to the islands.
>
> >> Isn't this unlikely?  Wouldn't the network administrators prefer a
>    structured and managed deployment method?
>
>    In cases where the network administrator is sure about the absence of
>    internal NAT and firewalls in the network, and end-nodes will need
>    only IPv6 /128 address, a tunneling protocol satisfying only the
>    basic requirements will suffice.
>
> >> And there's no need for IPv6 address stability, or extensibility in
>    the network (to be consistent with 6.2)
>
>    A zero-configuration tunneling mechanism should satisfy the basic
>    requirements (see section 6.1) and should take into account the
>    specific requirements described below.
>
> >> Why are they below and not just in section 6??   The requirements
>    are being repeated in the scenario sections, bloating the text.
>
> 9.4.1  IPv4-in-IPv6 Tunneling
>
>    The tunneling Protocol should be able to handle automatic
>    establishment of IPv4-in-IPv6 tunnels.  It must be able to handle
>    assignment of temporary IPv4 address and other tunnel parameters as
>    required.
>
> >> This is a new one, and only suggested higher up in the doc, I
>    would cite it as an advanced requirement?
>
> 10.  ISP Network Specific Requirements
>
>    In a scenario where connection to customer from ISP supports both
>    IPv4 and IPv6, but the customer has IPv6-only network and the ISP
>    backbone is IPv4-only, IPv6 packets from customer needs to be
>    tunneled over the IPv4 backbone to the next upstream ISP.
>    Zero-configuration tunneling mechanism can be used in such scenario
>    as well.
>
> >> So it's being used for a whole network here, not a node?
>
>
>




From owner-v6ops@ops.ietf.org  Mon Nov  8 07:42:26 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29077
	for <v6ops-archive@lists.ietf.org>; Mon, 8 Nov 2004 07:42:26 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CR8o8-000AZf-7p
	for v6ops-data@psg.com; Mon, 08 Nov 2004 12:39:40 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CR8o6-000AZH-1L
	for v6ops@ops.ietf.org; Mon, 08 Nov 2004 12:39:38 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id iA8CVZq09880;
	Mon, 8 Nov 2004 14:31:35 +0200
Date: Mon, 8 Nov 2004 14:31:35 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: Brian E Carpenter <brc@zurich.ibm.com>
cc: IPv6 Operations <v6ops@ops.ietf.org>
Subject: Re: IPv6 Network Architecture Protection draft
In-Reply-To: <416E3232.6090701@zurich.ibm.com>
Message-ID: <Pine.LNX.4.61.0411081430140.9056@netcore.fi>
References: <416E3232.6090701@zurich.ibm.com>
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="1589707168-988632757-1099917095=:9056"
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--1589707168-988632757-1099917095=:9056
Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8BIT

On Thu, 14 Oct 2004, Brian E Carpenter wrote:
> The authors would be interested in comments on the draft below.

Thanks.  Mine below. I think this is an important and very 
well-written draft.

I recognize a number of recommendations/v6 approaches which I 
definitely don't like, but would rather see changed (if it was 
possible), but because this draft is meant more as a political 
document I understand why those (more or less) have to be in there...

substantial
-----------

2.  Perceived benefits of NAT and its impact on IPv4

    This section provides visibility into the generally perceived
    benefits of the use of IPv4 NAT.  The goal of this description is not
    to analyze these benefits or discus the rightfulness of the
    perception, but to identify the connectivity and security
    prerequisites to deploy IPv6 to functionally replace IPv4 combined
    with a NAT device.

==> as said above, this is a practically good approach at finishing this
document in finite time.  I just hope it would have been possible to insert
some enlightenment, possibly a subsection per existing subsection, saying
why a particular concern is not such a big problem or is a bad idea.  You
never know, someone could even be convinced about it.... :-)

2.6.2  Small private networks
2.6.3  Single user connection

==> do we dare to mention some ISPs' business models here, i.e., NAT helps
the customer to deploy as many devices as he wants in even residential,
cheapo access deal?  ISP could force the user's hand if ISP only gave
/128's.  On the other hand, then the user can just use tunneling like Teredo
or 6to4, and get v4-dependent v6 address space regardless of the ISP.

    This simple rule would create similar protection and security holes
    the typical IPv4 NAT device will offer and may for example be enabled
    by default on all broadband edge-routers.  but with that difference
    that the security caveats will be documented, and may hence be
    removed with the next revision of the rule.

==> this also needs to discuss how to not throw away the baby with the
bathwater, i.e., how one could deploy e.g. new apps (like p2p) without
having to do the same kind of firewall traversal as v4.  This probably
would need some signalling mechanism or something.. Probably an issue to be
investigated.

   An alternative method to hide the internal topology would be to use
    MIPv6 internally where the public facing addresses (HA) are
    consolidated on an edge Home Agent, then use MIP in tunnel mode to
    the ULA as a COA.  This truly masks the internal topology as all
    nodes with global access appear to share a common subnet.  (it
    wouldn't really need to be a single subnet either so local policy can
    run rampant trying to obscure addressing correlations.) There is no
    reason that rack mounted devices shouldn't be considered mobile nodes
    to mask the internal topology.

==> You're referring to using MIPv6 in a MIPv4-like manner, e.g., using
bidirectional tunneling only, no route optimization.  This should be stated
out explicitly. That's equivalent to running a VPN to a central server.
This has issues e.g. relating to scalability and reliability of the server
which should also be at least briefly mentioned.

NOTE:

    Is all of the material in this section, specifically the material
    that does not directly address the "advantages" of IPv4 NAT,
    necessary?

==> agree, most of this is irrelevant here.  I'd suggest, unless something
else is figured out, to moving the non-relevant parts to an appendix and
figuring out later what should be the final destiny..




semi-editorial
--------------

    Once a list of available devices and IP addresses has been mapped, a
    port-scan on these IP addresses can be performed.  A port scan is an
    automated procedure of initiating sessions on every specified TCP
    port to see whether the host replies.  If it does, a service is
    running on the target port of the machine.  Different services run on
    default ports.  For example, FTP usually runs on port 21, and HTTP
    usually runs on port 80.  These open port cold be used for initiating
    attacks on an end system.

==> there's UDP port scanning as well, in case the firewall is returning
port unreachables for the unfiltered ports (which tells which ports are
passed by the firewall, or if there is no firewall, which ports are open at
the host).

==> this and a couple of other sections go a bit unnecessary in depth to
describe e.g., what port scanning is, but considering the target audience
this is probably a good idea..

2.5  Independent control of addressing in a private network
2.7  Multihoming and renumbering with NAT

==> these seem to be more tightly coupled, so would it make good sense to
move 2.7 as 2.6, and rename 2.6 as 2.7 (and respectively)?  If not, there
should be a pointer from 2.5 (last paragraph) to section 2.7.

    Based on the amount of connections and required network services the
    network design and addressing dynamics are different.

==> what "connections"?  _simultaneous_?  TCP connections or flows in
general?


    3.  The size of the typical subnet ::/64 will make a network ping
        sweep and resulting port-scan virtually impossible due to the
        amount of possible combinations available

==> make explict ref to Tim Chown's document ?

4.6.4  ISP/Carrier customer networks

==> this is roughly the same as 2.6.4, and needs to be updated ?
(nothing v6-specific here..)


5.1  Universal any-to-any connectivity

    One of the original design points of the Internet was any-to-any
    connectivity.  The dramatic growth of Internet connected systems
    coupled with the limited address space of the IPv4 protocol spawned
    address conservation techniques.  NAT was introduced as a tool to
    reduce demand on the limited IPv4 address pool, but the side effect
    of the NAT technology was to remove the any-to-any connectivity
    capability.  By removing the need for address conservation (and
    therefore NAT), IPv6 returns the any-to-any connectivity model and
    removes the limitations on application developers.  With the freedom
    to innovate unconstrained by NAT traversal efforts, developers will
    be able to focus on new advanced network services (i.e.  peer-to-peer
    applications, IPv6 embedded IPsec communication between two
    communicating devices, instant messaging, Internet telephony, etc..)
    rather than focusing on discovering and traversing the increasingly
    complex NAT environment.


==> maybe this needs reference to the default firewall policy section, and
the caveat about that causing issues for new any-to-any apps..

   IPv6 allows also for innovative usage of the IPv6 address length, and
    makes it possible to embed the multicast 'Rendez-Vous Point' (or RP)
    directly in the IPv6 multicast address when using ASM multicast.
    this is not possible with limited size of the IPv4 address.

==> I guess it might also be worth saying that using this approach
simplifies the multicast model considerably, making it easier to understand
and to deploy.

    o  IPv6 has the IPsec technology embedded directly embedded into the
       IPv6 protocol.  This allows for simpler peer-to-peer encryption
       and authentication, while the usage of some other less secure
       mechanisms is avoided (i.e.  md5 password hash for neighbor
       authentication)

==> in all fairness, there is still the small matter of key/trust management
to consider, unless an opportunistic IPsec model is acceptable..

    o  On a local network, any user will have more security awareness.
       This awareness will motivate the usage of simple firewall
       applications/devices to be inserted on the border between the
       external network and the local (or home network).

==> I didn't understand what this tried to say..

    o  The technology to enable source-routing on a network
       infrastructure has been enhanced to allow this feature to
       function, without impacting the processing power of intermediate
       network devices.  The only devices impacted with the
       source-routing will be the source and destination node and the
       intermediate source-routed nodes.  This impact behavior is
       different if IPv4 is used, because then all intermediate devices
       would have had to look into the source-route header.  Looking into
       the source-route header consumed CPU power of these devices and
       was generally discouraged to be enabled on a network due to
       potential Denial-of-Service attack potential.

==> this is technically not correct.  Both v4 and v6 behave the same way;
the routing header is only processed by those nodes who are at the
destination address (before it's changed), so on-path nodes don't need to
peek at the packets.  I suggest this bullet be removed.

6.  IPv6 gap analysis

    Like IPv4 and any major standards effort, IPv6 standardization work
    continues as deployment starts.

==> "as deployment starts" sounds as if deployment has not started yet ;-). 
Maybe "is ongoing"?

8.  Security Considerations

    Various security and privacy benefits of both IPv4 NAT and native
    IPv6 are discussed throughout this document.  It does not introduce
    any new security concerns.

==> this section will probably need to expand a bit, but I guess it's OK to
keep it as is for now, to see how the recommendations develop.

11  References

==> need to be split to normative/informative


editorial
---------

    to analyze these benefits or discus the rightfulness of the

==> s/discus/discuss/

    which member of a family, which customer of an Internet caf‰, or

==> s/caf[weird character here]/cafe/

    of NAT to avoid the ongoing operational complexity of overlapping
    addresses

==> add "." at the end.

    An example of a potential rule could be:

==> s/rule/set of firewall rules/

    This simple rule would create similar protection and security holes
    the typical IPv4 NAT device will offer and may for example be enabled
    by default on all broadband edge-routers.  but with that difference
    that the security caveats will be documented, and may hence be
    removed with the next revision of the rule.

==> s/but/But/, or something missing there?

4.5  independent control of addressing in a private network

==> s/in/In/

    route-injection could be done based on ::/128 host-routes to each

==> remove "::".

4.6.2  small private networks

==> s/small/Small/

    Operation Center (NOC) and are using either a dial-up connection or
    broadband access..

==> remove the other "."

    o  IPv6 has the IPsec technology embedded directly embedded into the

==> kill extra "embedded"

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



From owner-v6ops@ops.ietf.org  Mon Nov  8 07:51:33 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00247
	for <v6ops-archive@lists.ietf.org>; Mon, 8 Nov 2004 07:51:32 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CR8z6-000BwC-Ob
	for v6ops-data@psg.com; Mon, 08 Nov 2004 12:51:00 +0000
Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CR8z4-000Bvq-55
	for v6ops@ops.ietf.org; Mon, 08 Nov 2004 12:50:58 +0000
Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131])
	by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id iA8CovGp013466
	for <v6ops@ops.ietf.org>; Mon, 8 Nov 2004 12:50:57 GMT
Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162])
	by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id MAA24291
	for <v6ops@ops.ietf.org>; Mon, 8 Nov 2004 12:50:55 GMT
Received: (from tjc@localhost)
	by login.ecs.soton.ac.uk (8.11.6/8.11.6) id iA8Cot132073
	for v6ops@ops.ietf.org; Mon, 8 Nov 2004 12:50:55 GMT
Date: Mon, 8 Nov 2004 12:50:55 +0000
From: Tim Chown <tjc@ecs.soton.ac.uk>
To: v6ops@ops.ietf.org
Subject: Comments on draft-vandevelde-v6ops-nap-00
Message-ID: <20041108125055.GA31930@login.ecs.soton.ac.uk>
Mail-Followup-To: v6ops@ops.ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.4i
X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information
X-ECS-MailScanner: Found to be clean
X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit

Overall, very nice thrust :)


   has some perceived benefits.  Indeed, in an Internet model based on
   universal any-to-any connectivity, product marketing departments have
   driven a perception that some connectivity and security concerns can
   only be solved by using a NAT device or by using logically separated
   LAN address spaces.  

>> But it's not any-to-any, is it?  Maybe "originally based on the concept
   of universal any-to-any connectivity, this concept has been stifled by
   product marketing departments who have sold consumers a perception..."
   (and as a result, we have an Internet of consumers...)

   This document describes the market perceived
   reasons to utilize a NAT device in an IPv4 environment and shows how
   these needs can be met and even exceeded with native IPv6.  The use

>> What do you mean by "native" here?  (some readers may not know)

   This document describes several techniques that may be combined on an
   IPv6 site to protect the integrity of its network architecture.
   These techniques, known collectively as NAP, retain the concept of a
   well defined boundary between "inside" and "outside" the private
   network, and allow firewalling, topology hiding, and privacy and
   achieve these goals without address translation.

>> Are we concerned with address translation here, or use of private (site
   local) addresses?   The latter has no translation, but may leak...

2.  Perceived benefits of NAT and its impact on IPv4

2.2  Simple security due to stateful filter implementation

   It is frequently believed that a NAT device puts in an extra barrier
   to keep the private network protected from evil outside influences
   due to the stateful character of NAT technology (to protect against
   hackers, worms, etc..).  

>> I'd not say "evil" even if it is :)

>> Also, "stateful" isn't the thing, it's that the internal (private)
   addresses cannot (usually) be routed to/contacted from outside the 
   private network.

   This benefit may be partially real; however,
   experienced hackers are well aware of NAT devices and are very
   familiar with the private address space, and hence the secure feeling
   is in vain.

>> A little wooly; perhaps specify the vulnerability in more detail.

   Address translation does not provide security on itself; for example,
   consider a configuration with static NAT translation and all ports
   translating to a single machine.  In such a scenario the security
   risk for that machine is identical as if there were no NAT device in
   the communication path.  As result there is no specific security
   value in the address translation function.  The perceived security
   comes from the lack of pre-established mapping state.  Dynamically
   establishing state in response to internal requests reduces the
   threat of unexpected external connections to internal devices.

>> And of course many vulnerabilities these days are not from IP-based
   connections into a network, but from data received by the network
   (emails, images, web pages, etc).   NAT is just a piece of the picture.

>> Some NAT users will also map ports to enable services into their
   NATed network; here the NAT adds complexity; not sure that's captured
   in the draft?

2.3  User/Application tracking

   Due to the fact that NAT is a stateful technology, it could provide
   limited capabilities for the administrator of the NAT to gather
   information about who in the private network is requesting access to
   which Internet location.  This can be done by checking the network
   address translation details of the private and the public addresses
   of the NAT devices state-database.

>> But this can be done (and is done) with non-NATed networks?.

2.4  Privacy and topology hiding

   The ability NAT to provide internet access by the use of a single (or
   few) global IPv4 routable addresses to a large community of users
   offers a simple mechanism to hide the internal topology of a network.
   In this example the large community will be reflected in the internet
   by a single (or few) IPv4 address(es).

   The use of NAT then results in a user behind a NAT gateway actually
   appearing on the Internet as a user inside the NAT box itself; i.e.,
   the IPv4 address that appears on the Internet is only sufficient to
   identify the NAT.  Thus it is impossible to tell from the outside
   which member of a family, which customer of an Internet cafâ, or
   which employee of a company generated or received a particular
   packet, if concealed behind NAT.  Thus, although NATs do nothing to
   provide application level privacy, they do prevent the external
   tracking and profiling of individual host computers by means of their
   IP addresses.  At the same time it creates a smaller pool of
   addresses for a much more focused point of attack.

>> There is a similarity with app-level, in that a NAT offers similar
   "privacy" for web users as a web cache (although the details of what
   is - or is not - logged at the NAT/proxy will be deifferent).

   Some enterprises prefer to hide as much as possible of their internal
   network topology from outsiders.  Mostly this is achieved by blocking
   "traceroute" etc., but NAT of course entirely hides the internal
   subnet topology, which some network managers believe is a useful
   precaution to mitigate scanning attacks.

>> Perhaps talk somewhere about two-faced DNS, which is used to 
   support this model.

>> Also scanning in v6 can be much harder, by obscurity (see
   draft-chown-v6ops-port-scanning-implications-01)

2.5  Independent control of addressing in a private network

   Due to the ongoing depletion of the IPv4 address range, the remaining
   pool of unallocated IPv4 addresses is below 30%.  Recent consumption
   rates are over 7% of the total IPv4 space per year.  This run rate
   leaves about 4 years to deplete the remaining unallocated pool.  

>> Recent IETF list discussion would "debate" these numbers :)

   Many private IPv4 networks take benefit from using the address space
   defined in RFC 1918 to enlarge the available addressing space for
   their private network, and at the same time reduce their need for
   globally routable addresses.  This type of local control of address
   resources allow a clean and hierarchical addressing structure in the
   network.

>> But v6 addressing for the enterprise is a /48 (in effect a Class A
   of v4 address space, but with 2^64 hosts per subnet not 2^8).  

>> With v6, you are far less likely to need to go back to ask for more
   address space (with the paperwork that goes with that).

>> With v6, you don't have to resize subnets to use v4 address space
   efficiently; an enterprise today may have a mix of /28 - /23 size
   subnets for example, and may shrink/grow these as their network
   user base/etc changes.  In v6, it's all /64.

   Another benefit is due to the usage of independent addresses on
   majority of the network infrastructure there is an increased ability
   to change provider with less operational difficulties.

>> This is a BIG plus for v4 today; no PI addressing in v6.

2.6.1  Medium/large private networks

   Under this category fall the majority of private enterprise networks.
   Many of these networks have one or more exit points to the Internet.
   There are several reasons why NAT be be used in such a network.  For

>> "be be" -> "may be"

   the ISP there is no need to import the IPv4 address range from the
   remote end-customer, which facilitates IPv4 address summarization.
   The customer can use a larger IPv4 address range (probably with
   less-administrative overhead) by the use of RFC 1918 and NAT.  The
   customer also reduces the overhead in changing to a new ISP, because
   the addresses assigned to devices behind the NAT do not need to be
   changed when the customer is assigned a different address by a new
   ISP.  Finally, the customer can provide privacy about its hosts and
   the topology of its internal network if the internal addresses are
   mapped through NAT.

>> So be more explicit and say "using NAT avoids the need for network 
   renumbering" and that "NAT can help support IPv4 site multihoming"
   (though of course both solutions have restrictions and come at a
   price)   You do mention this further down, I note,

2.6.3  Single user connection

   This group identifies the users which are connected via a single IPv4
   address and use a single piece of equipment (PC, PDA, etc.).  This
   user may get an ambiguous IPv4 address from the service provider
   which is based on RFC 1918.  If ambiguous addressing is utilized, the
   service provider will execute NAT on the allocated IPv4 address for
   global Internet connectivity.  This also limits the internet
   capability of the equipment to being mainly a receiver of Internet
   data, and makes it quite hard for the equipment to become a world
   wide internet server (i.e.  HTTP, FTP, etc.) due to the stateful
   operation of the NAT equipment.

>> Or you have a SOHO user with one NAT device (e.g. cable modem) and
   only one home PC.   That's different to receiving a private v4
   address that is NATed higher up the ISP network.

>> Also in Section 3, maybe mention that NAT is often not a customer
   choice; it's frequently imposed by the ISP, or deployed because the
   organisation outsourced its IT.

>> Is there an (obvious) new subsection for the case where the deploying
   network for some reason feels it is unable to get enough global v4
   address space, or the scenario is one where the number of attaching
   nodes is unknown (e.g. a WLAN provision at a conference or hotel?)

3.  Description of the IPv6 tools

   This section describes several features that can be used to provide
   the protection features associated with IPv4 NAT.

3.1  Privacy addresses (RFC 3041)

   There is nothing that prevents a DHCP server from running RFC 3041
   for any new MAC it hears, then remembering that for future queries.
   This would allow using them in DNS for registered services since the
   assumption would be a persistent value that minimizes DNS churn.

>> Any comment on the RFC3041-considered-harmful viewpoint here?

>> 3041 is very like v4 NAT in that 3041 doesn't protect the subnet ID
   just as NAT doesn't protect the v4 global address used.

3.2  Unique Local Addresses

   A unique local address (ULA) is an IPv6 unicast address format that
   is globally unique and is intended for local communications [12].
   These are expected NOT to be routed on the global Internet.  They are
   routable inside of a more limited area defined by a local network
   administrator.

>> Note also draft-ietf-ipv6-ula-central-00, i.e. the ULA itself may
   not be unique, whereas the centrally assigned prefixes should be.
   For sites looking to merge without use of NAT, the central method
   would give a greater assurance of no clash.

3.4  Untraceable IPv6 addresses

   These are globally routable IPv6 addresses which can be randomly and
   dynamically assigned to IPv6 devices and are globally aggregatable
   addresses assigned to the local network by either a registry or
   connecting ISP.  The random assignment has as purpose to confuse the
   outside world on the structure of the local network, while for the
   local network the location of the randomly assigned IPv6 address is
   known and connectivity inside the local network can exist.  The goal
   is to create a network infrastructure which appears from external
   networks with an unpredictable structure, to avoid malicious events
   to happen to the local network.  When using untraceable IPv6
   addresses, it may be that two apparently sequential addresses are
   reachable on very different parts of the local network instead of
   belonging to the same subnet next to each other.

>> Is there a reference to this?  I'm not sure how this would actually
   be implemented, or of the drawbacks of doing so.

>> Maybe "infinitely" sized subnets are an IPv6 "tool", in that a
   subnet can absorb any number of hosts (in theory at least) without
   subnet resizing or needing to NAT (if the network had a Class C v4
   and might have more than 253 nodes attaching simultaneously).

>> Related is the issue of dynamic vs static address allocation; does
   the same node get the same IP address when attaching each time, or
   to conserve (v4) address space is the address dynamic?   If a 
   network has a Class C v4 and has 1,000 users of whom only 100 may
   be attached at any one time, in v4 you need dynamic addressing, 
   in v6 you don't.

4.1  Simple gateway between Internet and internal network

   The connection creation towards the global Internet hosts/systems
   will always happen with global IPv6 addresses.  An enterprise will
   typically receive a global IPv6 address prefix from his connecting
   IPv6 Service Provider.

>> "his" -> "its"

4.2  IPv6 and Simple security

   The vulnerability of an IPv6 host is similar as for an IPv4 host
   directly connected towards the Internet, and firewall and IDS systems
   are recommended.  However, with IPv6, the following protections are
   available without the use of NAT:

   1.  Short lifetimes on privacy extension suffixes reduce the attack
       profile since the node will not respond to the address once the
       address is no longer valid.

>> Important because with port-scanning very hard to do in v6, attackers
   will need to gather target addresses from various server log files,
   and then try these.

   2.  IPsec is a mandatory service for IPv6 implementations.  IPsec
       functions to prevent session hijacking, prevent content
       tampering, and optionally masks the packet contents.  While IPsec
       might be available in IPv4 implementations, deployment in NAT
       environments either breaks the protocol or requires complex
       helper services with limited functionality.

>> Or significant compromises in trust.

   3.  The size of the typical subnet ::/64 will make a network ping
       sweep and resulting port-scan virtually impossible due to the



Van de Velde, et al.     Expires April 12, 2005                [Page 11]

Internet-Draft    IPv6 Network Architecture Protection      October 2004


       amount of possible combinations available

>> See the port-scanning draft :)

   This simple rule would create similar protection and security holes
   the typical IPv4 NAT device will offer and may for example be enabled
   by default on all broadband edge-routers.  but with that difference
   that the security caveats will be documented, and may hence be
   removed with the next revision of the rule.  The goal is that every
   iteration, the IPv6 internet will become more secure for the
   oblivious users.

>> The snag is configuring this in home networking scenarios (for example)
   where today NAT "does the job"; as we require network access into the 
   home, how do we let Joe User say "my PDA can access my home DVR?".

   unrealistic) pings to map the network, and virus/worm propagation
   will be thwarted in the process At full rate 40Gbps (400 times the
   typical 100Mbps LAN, and 13,000 times the typical DSL/Cable access
   link) it takes over 5000 years to scan a single 64 bit space.

>> Again, see the port-scanning draft.   You may find other notes worth
   reusing in there.


4.4  Privacy and topology hiding using IPv6

   By using untraceable addresses, it is possible to only allocate
   certain parts of the internal network with global prefixes, while
   other, private network parts do not have global prefixes and remain
   totally cut off from the outside.  If an edge firewall is used (which
   is strongly suggested) a traffic policy can be implemented as today,
   based on various filtering and inspection rules.  (Older techniques
   such as application level proxies and SOCKS also remain available.)

>> Worth mentioning (two-faced) DNS issues here?

   If there is need to mask the internal structure towards the external
   IPv6 internet, then the usage of 'Untraceable' addresses may be used.
   These addresses will be derived from a local pool, and may be
   assigned to those hosts for which topology masking is required or
   which want to reach the IPv6 Internet or other external networks.

>> I think a separate I-D on "untraceable" addresses might be useful?

   The technology to assign these addresses to the hosts could be based
   on DHCPv6.  To complement the 'Untraceable' addresses it is needed to
   have at least awareness of the IPv6 address location when routing an
   IPv6 packet through the internal network.  This could be achieved by
   'route-injection' in the network infrastructure.  This
   route-injection could be done based on ::/128 host-routes to each
   device that wants to connect to the Internet. 

>> I think you make a good point about scalability; need to have some 
   clearer idea of the tradeoffs here?  (or in the separate I-D)

4.6.2  small private networks

   The category describes those networks which only have only few
   routers in the topology, and have a single network egress point.
   These networks are also known as SOHO (Small Office/Home Office)
   networks.  Typically these networks don't have dedicated Network
   Operation Center (NOC) and are using either a dial-up connection or
   broadband access..

>> Most SOHO networks are single (access) router networks?

4.6.4  ISP/Carrier customer networks

   This group refers to the actual service providers that are providing
   the IP access.  They tend to have three separate IP domains that they
   support.  For the first they fall into the Medium/large private
   networks category (above) for their own internal networks, LANs etc.
   and will be able to use the same solutions as above.  The second is
   their Operations network which addresses their backbone and access
   switches, and other hardware, this is separate for both engineering
   reasons as well as simplicity in managing the security of the
   backbone, for this it is again possible to configure a single range
   of addresses with the defined local scope defined in order to prevent
   these from being accessed from the public network.  The third is the
   IP addresses (single or blocks) that they assign to customers.  These
   can be registered addresses (usually given to category a and b and
   sometimes c) or can from a pool of RFC 1918 addresses used with NAT
   for single user connections.  Therefore they can actually have two
   different NAT domains that are not connected (internal LAN and single
   user customers) again this will be resolved by the large availability
   of addresses and the procedures mentioned above.

>> So the main gain is simplified network management for the operator?
   Or something else?   Might be useful to make it clear. 

4.7  Multihoming and renumbering

   The IPv6 address space allocated by the ISP will be dependent upon
   the connecting Service provider.  This may result in a renumbering
   effort if the enterprise changes from Service Provider.  To keep the

>> "from" -> "its"

   impact on the gateway when changing ISP to a zero human touch
   environment, DHCPv6 Prefix Delegation [10] can be used.

>> You might want to cite Fred's draft here if you don't already, and
   also draft-chown-v6ops-renumber-thinkabout-00.   One specific 
   scenario to add here for renumbering might be network mergers?

5.  Additional benefits due to Native IPv6 and universal unique
   addressing

   Is all of the material in this section, specifically the material
   that does not directly address the "advantages" of IPv4 NAT,
   necessary?

>> It is useful to document somewhere;  perhaps split into two sections,
   one in poker terms that "sees" IPv4 NAT, and one that raises the bet
   with IPv6?

5.1  Universal any-to-any connectivity

   One of the original design points of the Internet was any-to-any
   connectivity.  The dramatic growth of Internet connected systems
   coupled with the limited address space of the IPv4 protocol spawned
   address conservation techniques.  NAT was introduced as a tool to
   reduce demand on the limited IPv4 address pool, but the side effect
   of the NAT technology was to remove the any-to-any connectivity
   capability.  By removing the need for address conservation (and
   therefore NAT), IPv6 returns the any-to-any connectivity model and
   removes the limitations on application developers.  With the freedom
   to innovate unconstrained by NAT traversal efforts, developers will
   be able to focus on new advanced network services (i.e.  peer-to-peer
   applications, IPv6 embedded IPsec communication between two
   communicating devices, instant messaging, Internet telephony, etc..)
   rather than focusing on discovering and traversing the increasingly
   complex NAT environment.

>> There are some good "transparency" type RFCs from Brian and others
   that could be cited here.   2775 springs to mind.   Also RFC on
   implications of using NAT - 2993 I think.

5.2  Auto-configuration

   IPv6 offers a scalable approach to minimizing human interaction and
   device configuration.  Whereas IPv4 implementations require touching
   each end system to indicate the use of DHCP vs.  a static address and
   management of a server with the pool size large enough for the
   potential number of connected devices, IPv6 uses an indication from
   the router to instruct the end systems to use DHCP or the stateless
   auto configuration approach supporting a virtually limitless number
   of devices on the subnet.  This minimizes the number of systems that
   require human interaction as well as improves consistency between all
   the systems on a subnet.  In the case that there is no router to
   provide this indication, an address for use on the local link only
   will be derived from the interface media layer address.

>> Not sure about this.  Most OSes will do DHCP(v4) by default today,
   when connecting.  So "autoconfiguration" is there, but it requires
   DHCP to be set up somewhere by the "provider".   How widely used
   is the IPv4 link-local equivalent under 169. - seems to be mainly
   a Microsoft implemented mechanism?

5.3  Native Multicast services

   Multicast services in IPv4 were severely restricted by the limited
   address space available to use for group assignments and an implicit
   locally defined range for group membership.  IPv6 multicast corrects
   this situation by embedding explicit scope indications as well as
   expanding to 4 billion groups per scope.  In the source specific
   multicast case, this is further expanded to 4 billion groups per
   scope per subnet by embedding the 64 bits of subnet identifier into
   the multicast address.

   IPv6 allows also for innovative usage of the IPv6 address length, and
   makes it possible to embed the multicast 'Rendez-Vous Point' (or RP)
   directly in the IPv6 multicast address when using ASM multicast.
   this is not possible with limited size of the IPv4 address.

>> Cite Pekka's work on this?

>> Also make a comment about SSM and IPv6?   There seems to be a strong
   feeling that IPv6 is an opportunity to get SSM deployed more widely
   with its more streamlined architecture.

5.4  Increased security protection

   The security protection offered by native IPv6 technology is more
   advanced as with IPv4 technology.  There are various transport

>> "as with" -> "than"?

   mechanisms enhanced to allow a network to operate more secure with
   less performance impact:

>> "secure" -> "securely"

   o  On a local network, any user will have more security awareness.
      This awareness will motivate the usage of simple firewall
      applications/devices to be inserted on the border between the
      external network and the local (or home network).

>> I don't think users will be more security aware with IPv6, if they
   even know they're using IPv6.  I think with growing use of shared
   hotspots etc we'll see growing awareness of personal firewalls in
   general.

   o  The usage of private address-space in IPv6 still provides with

>> "is now provided by"

      Unique Local Addresses, which will avoid conflict situations when
      joining networks and securing the internal communication on a

>> "joining" -> "merging"

      local network infrastructure due to simpler traffic filtering
      policy

5.5  Mobility

   Anytime, anywhere, universal access requires mIPv6 services in

>> "MIPv6"

   support of mobile nodes.  While a Home Agent is required for initial
   connection establishment in either protocol version, IPv6 mobile
   nodes are able to optimize the path between them using the mIPv6

>> "MIPv6"

   option header while IPv4 mobile nodes are required to triangle route
   all packets.  In general terms this will minimize the network
   resources used and maximize the quality of the communication

>> eg. very useful when two mobile nodes in same WLAN with low bandwidth  
   uplink what to share data, to avoid the data passing over the uplink.

5.6   Merging networks

   With the usage of IPv6 the addressing overlap will not exist because
   of the existence of the Unique Local Address usage for private and
   local addressing.

>> As per above, note the difference between the two variants of ULA, one
   centrally assigned.

5.7  Community of interest

   Although some Internet-enabled devices will function as fully-fledged
   Internet hosts, it is believed that many will be operated in a highly
   restricted manner functioning largely or entirely within a Community
   of Interest.  By Community of Interest we mean a collection of hosts
   that are logically part of a group reflecting their ownership or
   function.  Typically, members of a Community of Interest need to
   communicate within the community but should not be generally
   accessible on the Internet.  They want the benefits of the
   connectivity provided by the Internet, but do not want to be exposed
   to the rest of the world.  This functionality will be available
   through the usage of NAP and native IPv6 dataflows, without any
   stateful device in the middle.

>> Also maybe talk about virtual organisation networks built on the fly?
   Very difficult to do in IPv4+NAT scenarios.   The nodes may also
   take part in other communications in general.

6.  IPv6 gap analysis

6.3  Minimal traceability of privacy addresses

   Privacy addresses (RFC 3041) may certainly be used within the
   enterprise to limit the traceability of external traffic flows, but
   they would still reveal the subnet address bits.  To eliminate this,
   some combination of privacy addresses with the previous two points is
   required, and this work remains to be done.

>> The use of privacy addresses is also itself generally detectable.

6.4  Renumbering procedure

   Documentation of site renumbering procedures [11] should be
   completed.  It should also be noticed that ULAs will help here too,
   since a change of ISP prefix will only affect hosts that need an
   externally routeable address as well as a ULA.

>> Also draft-chown-v6ops-renumber-thinkabout-00.   Are there downsides
   to using ULAs?  If so, these are not described in this text.  e.g. it
   requires all nodes to implement address selection as desired (favour
   ULA src for ULA dst, global src for global dst, etc).

6.6  Untraceable addresses

   The details of the untraceable addresses, along with any associated
   mechanisms such as route injection, must be worked out and specified.

>> A new I-D on this would be good.

>> What about a set of recommendations for a site?  Like "use ULAs if
   you want feature X", or is this just implied already?






From owner-v6ops@ops.ietf.org  Mon Nov  8 07:53:16 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00560
	for <v6ops-archive@lists.ietf.org>; Mon, 8 Nov 2004 07:53:16 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CR90z-000CBq-VW
	for v6ops-data@psg.com; Mon, 08 Nov 2004 12:52:57 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CR90y-000CBS-PT
	for v6ops@ops.ietf.org; Mon, 08 Nov 2004 12:52:57 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id iA8Cqnw10550;
	Mon, 8 Nov 2004 14:52:49 +0200
Date: Mon, 8 Nov 2004 14:52:49 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: Alain Durand <Alain.Durand@Sun.COM>
cc: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>, v6ops@ops.ietf.org
Subject: Re: endpoint discovery from reverse DNS [Re: other comments on
 draft-nielsen-v6ops-3GPP-zeroconf-goals-00. txt
In-Reply-To: <DE994B4C-2F76-11D9-AC14-00039376A6AA@sun.com>
Message-ID: <Pine.LNX.4.61.0411081436140.10001@netcore.fi>
References: <BDB16935.4E3CE%jordi.palet@consulintel.es>
 <Pine.LNX.4.61.0411051901430.18349@netcore.fi> <418BC6E6.5010906@sun.com>
 <Pine.LNX.4.61.0411052219540.23644@netcore.fi> <06AD28D4-2F73-11D9-AC14-00039376A6AA@sun.com>
 <Pine.LNX.4.61.0411052342440.24972@netcore.fi> <DE994B4C-2F76-11D9-AC14-00039376A6AA@sun.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

On Fri, 5 Nov 2004, Alain Durand wrote:
> On Nov 5, 2004, at 1:49 PM, Pekka Savola wrote:
>
>>  The point is that the other admins don't know it exists when they think of 
>> the problem they want to solve, and discredit the solution as requiring 
>> manual insertion for the lack of better tools.
>
> Honestly, this is FUD.

Whether true or not can be debated, but certainly something that would 
come up operationally.

...

A couple of afterthoughts..

From a higher view, another generic problem with reverse approach is 
that it does not work well (AFAICS) if the reverses have been 
delegated.  That will mean that each server has to do this 
configuration.  I don't know what's the typical procedure, but I'd 
expect e.g. bigger enterprises would have their own authorative 
servers for different bigger national branches, etc.  -- if yes, 
managing this information consistently is an operational challenge.

That said, the approach seems to be fairly good when you're only 
considering one administrative domain, and the tunnel point deployed 
in that administrative domain.  But isn't that scenario equally 
addressed with a DHCP option, using a more operator-friendly approach?

-- 
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 owner-v6ops@ops.ietf.org  Mon Nov  8 08:36:40 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05832
	for <v6ops-archive@lists.ietf.org>; Mon, 8 Nov 2004 08:36:40 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CR9gi-000HPs-TK
	for v6ops-data@psg.com; Mon, 08 Nov 2004 13:36:04 +0000
Received: from [193.180.251.53] (helo=eagle.ericsson.se)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CR9gh-000HPZ-Q1
	for v6ops@ops.ietf.org; Mon, 08 Nov 2004 13:36:04 +0000
Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118])
	by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id iA8Da3R2020430
	for <v6ops@ops.ietf.org>; Mon, 8 Nov 2004 14:36:03 +0100
Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211);
	 Mon, 8 Nov 2004 14:36:02 +0100
Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id WB161496; Mon, 8 Nov 2004 14:36:02 +0100
Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <VJQGNKVW>; Mon, 8 Nov 2004 14:36:02 +0100
Message-ID: <C26BB8276599A44B85D52F9CE41035E1050B9814@esealnt944.al.sw.ericsson.se>
X-Sybari-Trust: 5da87130 8cefd49f 418745b1 00000138
From: "Karen E. Nielsen (AH/LMD)" <karen.e.nielsen@ericsson.com>
To: "'Pekka Savola'" <pekkas@netcore.fi>,
        Alain Durand
	 <Alain.Durand@Sun.COM>
Cc: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>, v6ops@ops.ietf.org
Subject: RE: endpoint discovery from reverse DNS [Re: other comments on dr
	aft-nielsen-v6ops-3GPP-zeroconf-goals-00. txt
Date: Mon, 8 Nov 2004 14:36:01 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
X-OriginalArrivalTime: 08 Nov 2004 13:36:02.0988 (UTC) FILETIME=[E40B0EC0:01C4C597]
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk


> That said, the approach seems to be fairly good when you're only 
> considering one administrative domain, and the tunnel point deployed 
> in that administrative domain.  But isn't that scenario equally 
> addressed with a DHCP option, using a more operator-friendly approach?
> 

Dhcp isn't supported in all cases, dns is.

Karen
> -- 
> 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 owner-v6ops@ops.ietf.org  Mon Nov  8 08:38:24 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06100
	for <v6ops-archive@lists.ietf.org>; Mon, 8 Nov 2004 08:38:24 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CR9iN-000HdH-Vd
	for v6ops-data@psg.com; Mon, 08 Nov 2004 13:37:47 +0000
Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CR9iJ-000HcV-JN
	for v6ops@ops.ietf.org; Mon, 08 Nov 2004 13:37:43 +0000
Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131])
	by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id iA8DbgGn014557
	for <v6ops@ops.ietf.org>; Mon, 8 Nov 2004 13:37:42 GMT
Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162])
	by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id NAA27940
	for <v6ops@ops.ietf.org>; Mon, 8 Nov 2004 13:37:40 GMT
Received: (from tjc@localhost)
	by login.ecs.soton.ac.uk (8.11.6/8.11.6) id iA8DbeU00723
	for v6ops@ops.ietf.org; Mon, 8 Nov 2004 13:37:40 GMT
Date: Mon, 8 Nov 2004 13:37:40 +0000
From: Tim Chown <tjc@ecs.soton.ac.uk>
To: v6ops@ops.ietf.org
Subject: Re: Comments on draft-nielsen-v6ops-3GPP-zeroconf-goals-00
Message-ID: <20041108133740.GJ31930@login.ecs.soton.ac.uk>
Mail-Followup-To: v6ops@ops.ietf.org
References: <C26BB8276599A44B85D52F9CE41035E1050B980E@esealnt944.al.sw.ericsson.se>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <C26BB8276599A44B85D52F9CE41035E1050B980E@esealnt944.al.sw.ericsson.se>
User-Agent: Mutt/1.4i
X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information
X-ECS-MailScanner: Found to be clean
X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

Hi,

I can see the issue with 3gpp being in urgent need of a solution, but then
we could also say that (as far as I have read) that community has already
adopted isatap.   So the requirements are kind of being written up in
retrospect.

My view would be that if isatap meets the 3gpp zct requirements, fine, but 
we could still have the requirements in one document, since the requirements
should be definable for all four scenarios in one doucment (general 
assumptions, list of all requirements, then one section per scenario stating 
which requirements MUST or SHOULD be met for each scenario).

Currently we seem to have a 3gpp text with superfulous included requirements,
and a general zct text that includes 3gpp that - if we keep two texts -
should remove the 3gpp parts to avoid duplication (and probabe inconsistencies).

I think the chances of a single solution are now slim, if 3gpp runs with
isatap(*) (out of immediate need) while the WG develops a more generic "single"
solution applicable to all scenarios.    I think we should accept this fact,
but not let it cause divergence in the recorded requirements texts.

Tim

(*) Though there is a chance that isatap might be the general solution, I
    suspect this is unlikely.

On Mon, Nov 08, 2004 at 02:46:37AM +0100, Karen E. Nielsen (AH/LMD) wrote:
> Hi Tim,
> 
> The 3gpp draft could have been a separate chapter of 
> draft-suryanarayanan-v6ops-zeroconf-reqs-00.
> 
> I think it has been explained in length on the list why it isn't, but let
> me do it once more:
> 
> "Procedural":
> There's a certain urgency to solve the 3gpp case and as the 3gpp
> requirements, spelled out in the previous version of
> this document, was thought to be in a mature state it was judged
> best to keep this separate to avoid 
> the delay and the "blur" that could arise from integrating this into
> the generic zeroconf document.
> 
> As you point out in a different mail - then it is difficult to keep track of
> the generic requirements from the environment specific ones in the generic 
> zeroconf document.
> 
> Technical:
> The constrained conditions of 3gpp: bandwidth, round trips times (and costs)
> singles out the 3gpp environment compared to the other cases considered. 
> 
> These conditions may have implications that are in conflict with some of the 
> requirements for advanced features of the other scenarios. 
> 
> Something else:
> Having said this, it has been pointed out by many that given that the 3gpp document
> is indeed about 3gpp only, some "generic" zeroconf text should be removed
> and furthermore more text should be added on the explicit 3gpp deployment scenario.
> 
> BR, Karen
> 
> > -----Original Message-----
> > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On
> > Behalf Of Tim Chown
> > Sent: Monday, November 08, 2004 1:49 AM
> > To: v6ops@ops.ietf.org
> > Subject: Comments on draft-nielsen-v6ops-3GPP-zeroconf-goals-00
> > 
> > 
> > Hi,
> > 
> > I started reading draft-nielsen-v6ops-3GPP-zeroconf-goals-00, but I'm
> > not clear why we need this text rather than just reading
> > draft-suryanarayanan-v6ops-zeroconf-reqs-00 for the 3GPP part?
> > 
> > (In theory, draft-suryanarayanan-v6ops-zeroconf-reqs-00 could/should
> > list all the requirements, and each of the 4 scenario sections - 3gpp,
> > isp, unman, enterprise - should point at which requirements 
> > they carry?)
> > 
> > Will we thus see more simialr docs for unman, ent and isp?  
> > 
> > I'm confused :)
> > 
> > Tim
> > 

-- 
Tim

North American IPv6 Task Force Technologist Seminar
More info at http://www.ipv6seminar.com/



From owner-v6ops@ops.ietf.org  Mon Nov  8 08:51:27 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07890
	for <v6ops-archive@lists.ietf.org>; Mon, 8 Nov 2004 08:51:26 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CR9uV-000JDG-67
	for v6ops-data@psg.com; Mon, 08 Nov 2004 13:50:19 +0000
Received: from [203.254.224.33] (helo=mailout3.samsung.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CR9uK-000JBC-Im
	for v6ops@ops.ietf.org; Mon, 08 Nov 2004 13:50:08 +0000
Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com
 (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003))
 id <0I6V0011253IN9@mailout3.samsung.com> for v6ops@ops.ietf.org; Mon,
 08 Nov 2004 22:50:06 +0900 (KST)
Received: from ep_mmp1 (mailout3.samsung.com [203.254.224.33])
 by mailout3.samsung.com
 (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003))
 with ESMTP id <0I6V00IEV530HR@mailout3.samsung.com> for v6ops@ops.ietf.org;
 Mon, 08 Nov 2004 22:49:48 +0900 (KST)
Received: from Radhakrishnan ([107.108.71.58])
 by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004))
 with ESMTPA id <0I6V002J252YBE@mmp1.samsung.com> for v6ops@ops.ietf.org; Mon,
 08 Nov 2004 22:49:48 +0900 (KST)
Date: Mon, 08 Nov 2004 19:17:37 +0530
From: Radhakrishnan Suryanarayanan <rkrishnan.s@samsung.com>
Subject: Re: endpoint discovery from reverse DNS [Re: other comments on
 draft-nielsen-v6ops-3GPP-zeroconf-goals-00. txt
To: "Karen E. Nielsen (AH/LMD)" <karen.e.nielsen@ericsson.com>,
        "'Pekka Savola'" <pekkas@netcore.fi>,
        Alain Durand <Alain.Durand@Sun.COM>
Cc: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>, v6ops@ops.ietf.org
Reply-to: Radhakrishnan Suryanarayanan <rkrishnan.s@samsung.com>
Message-id: <01f401c4c599$831a65f0$3a476c6b@sisodomain.com>
Organization: SAMSUNG India Software Operations
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: 
 <C26BB8276599A44B85D52F9CE41035E1050B9814@esealnt944.al.sw.ericsson.se>
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7BIT



> 
> > That said, the approach seems to be fairly good when you're only 
> > considering one administrative domain, and the tunnel point deployed 
> > in that administrative domain.  But isn't that scenario equally 
> > addressed with a DHCP option, using a more operator-friendly approach?
> > 
> 
> Dhcp isn't supported in all cases, dns is.
I too agree with this point. :)

> 
> Karen
> > -- 
> > 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 owner-v6ops@ops.ietf.org  Mon Nov  8 09:31:32 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12486
	for <v6ops-archive@lists.ietf.org>; Mon, 8 Nov 2004 09:31:32 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CRAXo-000OVa-OE
	for v6ops-data@psg.com; Mon, 08 Nov 2004 14:30:56 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CRAXf-000OTm-Ji
	for v6ops@ops.ietf.org; Mon, 08 Nov 2004 14:30:48 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id iA8EUIi13264;
	Mon, 8 Nov 2004 16:30:18 +0200
Date: Mon, 8 Nov 2004 16:30:17 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: "Karen E. Nielsen (AH/LMD)" <karen.e.nielsen@ericsson.com>
cc: Alain Durand <Alain.Durand@Sun.COM>,
        JORDI PALET MARTINEZ <jordi.palet@consulintel.es>, v6ops@ops.ietf.org
Subject: RE: endpoint discovery from reverse DNS [Re: other comments on dr
 aft-nielsen-v6ops-3GPP-zeroconf-goals-00. txt
In-Reply-To: <C26BB8276599A44B85D52F9CE41035E1050B9814@esealnt944.al.sw.ericsson.se>
Message-ID: <Pine.LNX.4.61.0411081626040.13090@netcore.fi>
References: <C26BB8276599A44B85D52F9CE41035E1050B9814@esealnt944.al.sw.ericsson.se>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

On Mon, 8 Nov 2004, Karen E. Nielsen (AH/LMD) wrote:
>> That said, the approach seems to be fairly good when you're only
>> considering one administrative domain, and the tunnel point deployed
>> in that administrative domain.  But isn't that scenario equally
>> addressed with a DHCP option, using a more operator-friendly approach?
>
> Dhcp isn't supported in all cases, dns is.

Agreed for 3GPP.  Not sure if I see other major scenarios. (All the 
ISP cases are all in the different administrative domain.)

But how many of these cases are such that a DNS search-path based 
approach would not be suitable (due to the requirement to have more 
control on which tunnel endpoints each are selected by which node, as 
pointed out by Alain)?

-- 
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 owner-v6ops@ops.ietf.org  Mon Nov  8 11:11:57 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25396
	for <v6ops-archive@lists.ietf.org>; Mon, 8 Nov 2004 11:11:57 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CRC65-0009vC-PI
	for v6ops-data@psg.com; Mon, 08 Nov 2004 16:10:25 +0000
Received: from [63.240.218.73] (helo=s-utl01-dcpop.stsn.com)
	by psg.com with smtp (Exim 4.41 (FreeBSD))
	id 1CRC5y-0009uG-OG
	for v6ops@ops.ietf.org; Mon, 08 Nov 2004 16:10:18 +0000
Received: from dcpop.smtp.stsn.com ([127.0.0.1])
 by s-utl01-dcpop.stsn.com (SAVSMTP 3.1.0.29) with SMTP id M2004110811101123203
 for <v6ops@ops.ietf.org>; Mon, 08 Nov 2004 11:10:11 -0500
Received: from [10.67.86.144] ([10.67.86.144]) by dcpop.smtp.stsn.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Mon, 8 Nov 2004 11:10:11 -0500
Message-ID: <418F9AC5.4080905@sun.com>
Date: Mon, 08 Nov 2004 08:11:49 -0800
From: Alain Durand <Alain.Durand@sun.com>
User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20040906
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Pekka Savola <pekkas@netcore.fi>
CC: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>, v6ops@ops.ietf.org
Subject: Re: endpoint discovery from reverse DNS [Re: other comments on draft-nielsen-v6ops-3GPP-zeroconf-goals-00.
 txt
References: <BDB16935.4E3CE%jordi.palet@consulintel.es> <Pine.LNX.4.61.0411051901430.18349@netcore.fi> <418BC6E6.5010906@sun.com> <Pine.LNX.4.61.0411052219540.23644@netcore.fi> <06AD28D4-2F73-11D9-AC14-00039376A6AA@sun.com> <Pine.LNX.4.61.0411052342440.24972@netcore.fi> <DE994B4C-2F76-11D9-AC14-00039376A6AA@sun.com> <Pine.LNX.4.61.0411081436140.10001@netcore.fi>
In-Reply-To: <Pine.LNX.4.61.0411081436140.10001@netcore.fi>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 08 Nov 2004 16:10:12.0022 (UTC) FILETIME=[6CE5A560:01C4C5AD]
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Pekka Savola wrote:

> That said, the approach seems to be fairly good when you're only 
> considering one administrative domain, and the tunnel point deployed 
> in that administrative domain.  But isn't that scenario equally 
> addressed with a DHCP option, using a more operator-friendly approach?

The practical problem with the DHCP approach is that you need to update 
both the DHCP server
and all the DHCP clients, which is very difficult because of all the 
legacy systems.
In a typical home network, the soho router act as the local DHCP server 
for the local hosts,
and it also sometimes act as a DHCP client to get config from the ISP.
In that scenario, using DHCP won't work unless you are ready to change 
all the CPEs...

So I echo what Karen said, DHCP is not a practical avenue.

    - Alain.





From owner-v6ops@ops.ietf.org  Mon Nov  8 11:18:53 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26145
	for <v6ops-archive@lists.ietf.org>; Mon, 8 Nov 2004 11:18:52 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CRCDz-000Afk-CM
	for v6ops-data@psg.com; Mon, 08 Nov 2004 16:18:35 +0000
Received: from [63.240.218.73] (helo=s-utl01-dcpop.stsn.com)
	by psg.com with smtp (Exim 4.41 (FreeBSD))
	id 1CRCDv-000Adx-Eh
	for v6ops@ops.ietf.org; Mon, 08 Nov 2004 16:18:31 +0000
Received: from dcpop.smtp.stsn.com ([127.0.0.1])
 by s-utl01-dcpop.stsn.com (SAVSMTP 3.1.0.29) with SMTP id M2004110811183026914
 for <v6ops@ops.ietf.org>; Mon, 08 Nov 2004 11:18:30 -0500
Received: from [10.67.86.144] ([10.67.86.144]) by dcpop.smtp.stsn.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Mon, 8 Nov 2004 11:18:30 -0500
Message-ID: <418F9CB8.20801@sun.com>
Date: Mon, 08 Nov 2004 08:20:08 -0800
From: Alain Durand <Alain.Durand@sun.com>
User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20040906
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Pekka Savola <pekkas@netcore.fi>
CC: "Karen E. Nielsen (AH/LMD)" <karen.e.nielsen@ericsson.com>,
        JORDI PALET MARTINEZ <jordi.palet@consulintel.es>, v6ops@ops.ietf.org
Subject: Re: endpoint discovery from reverse DNS [Re: other comments on dr
 aft-nielsen-v6ops-3GPP-zeroconf-goals-00. txt
References: <C26BB8276599A44B85D52F9CE41035E1050B9814@esealnt944.al.sw.ericsson.se> <Pine.LNX.4.61.0411081626040.13090@netcore.fi>
In-Reply-To: <Pine.LNX.4.61.0411081626040.13090@netcore.fi>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 08 Nov 2004 16:18:30.0528 (UTC) FILETIME=[9607A000:01C4C5AE]
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Pekka Savola wrote:

>
> But how many of these cases are such that a DNS search-path based 
> approach would not be suitable (due to the requirement to have more 
> control on which tunnel endpoints each are selected by which node, as 
> pointed out by Alain)?

Any large network that spans different locations and uses potentially 
multiple domains.
This is true for large enterprise networks, but also at home if the user 
decided to have its
own local domain advertized through DHCP. For example, at home, my local 
DHCP
server is configured to send a search path as "sun.com" and 
"mylocaldomain.example.com",
but not "myISP.example.com"

So if i was to use the DNS search path in the forward tree, I would 
end-up looking for
Tunnel-end-point.sun.com or Tunnel-end-point.mylocaldomain.example.com 
but never
for the right thing, that is Tunnel-end-point.myISP.example.com.

To paraphase what Rob Austien once said about automatic completion using 
domain search list,
when you do not know what the question you ask is, don't be surprised if 
you don't find the answer.

In other words, you should never believe that is advertized as your 
domain name
is relevant to figure out where you are physically on the network.

    - Alain.




From owner-v6ops@ops.ietf.org  Mon Nov  8 11:42:10 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28629
	for <v6ops-archive@lists.ietf.org>; Mon, 8 Nov 2004 11:42:10 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CRCaE-000DHu-39
	for v6ops-data@psg.com; Mon, 08 Nov 2004 16:41:34 +0000
Received: from [193.252.22.25] (helo=mwinf0604.wanadoo.fr)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CRCaB-000DFi-LL
	for v6ops@ops.ietf.org; Mon, 08 Nov 2004 16:41:32 +0000
Received: from me-wanadoo.net (localhost [127.0.0.1])
	by mwinf0604.wanadoo.fr (SMTP Server) with SMTP
	id 8A7B728001B1; Mon,  8 Nov 2004 17:41:30 +0100 (CET)
Received: from wwinf0603 (wwinf0603 [172.22.137.30])
	by mwinf0604.wanadoo.fr (SMTP Server) with ESMTP
	id 7B34A2800191; Mon,  8 Nov 2004 17:41:30 +0100 (CET)
Message-ID: <11964125.1099932090496.JavaMail.www@wwinf0603>
From: =?iso-8859-1?Q?R=E9mi_DESPRES?= <remi.despres@wanadoo.fr>
Reply-To: remi.despres@wanadoo.fr
To: Elwyn Davies <elwynd@nortelnetworks.com>, v6ops <v6ops@ops.ietf.org>
Subject: Re: NAT-PT: To deprecate or not to deprecate: the question for next
 week's v6ops discussion
Mime-Version: 1.0
Content-Type: multipart/alternative; 
	boundary="----=_Part_102015_24271624.1099932090491"
X-Originating-IP: [130.129.133.176]
X-WUM-FROM: |~|
X-WUM-TO: |~||~|
X-WUM-REPLYTO: |~|
Date: Mon,  8 Nov 2004 17:41:30 +0100 (CET)
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,HTML_MESSAGE 
	autolearn=ham version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

------=_Part_102015_24271624.1099932090491
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

SUMMARY

Some simple variant of NAT-PT, say NAT6,  has to be available for IPv4 to
IPv4 transition.
To avoid unnecessary difficulties, its scope should be limited to:
  - Client hosts at IPv6-only addresses which call IPv4-only hosts
  - Client hosts which get their destination addresses by themselves (no
need for DNS record translations in NAT6).
  - IPv4 applications which are accessible via simple IPv4 NATs (no need fo=
r
application level gateways in NAT6).
  - Network paths which support at least 1280 octets packets (no need for
fragmentation support in NAT6)


ANALYSIS

  KEY QUESTION 1 is:
- Will  IPv6 hosts having no global IPv4 address be able to reach all IPv4
servers and applications which IPv4 clients behind private NATs can reach?
- A "yes" answer will clearly facilitate deployment of IPv6 addresses.
- Then some stateful address translation (some kind of NAT-PT) is
unavoidable somewhere.

 KEY QUESTION 2 is then:
- Can IETF specify a workable solution? (Issues raised in
"draft-aoun-v6ops-natpt-deprecate-00"  have to be dealt with.)

 ANSWER TO QUESTION 2

The following list of issues is that of
"draft-aoun-v6ops-natpt-deprecate-00" , with approaches  to resolve them
between brackets :

 1. Issues which are independent of the use of a DNS-ALG:

    1.1 Disruption of all protocols which embed IP addresses (and/or  ports=
)
in packet payloads or which apply integrity mechanisms using IP addresses
(and ports).
          [*The scope of NAT-PT should be restricted to IPv4-NAT compatible
applications.*]
   1.2 Inability to re-direct traffic for protocols not built on top of
specific transport layer protocols in situations where one NAPT-PT is
translating for multiple IPv6 hosts.
         [*The scope of NAT-PT should be restricted to IPv4-NAT compatible
applications.*]
   1.3  Requirement for applications to use keep alive mechanisms to
workaround connectivity issues caused by premature NAT-PT state timeout.
         [*The scope of NAT-PT should be restricted to IPv4-NAT compatible
applications.*]
   1.4  Loss of information due to incompatible semantics between IPv4 and
IPv6 versions of headers and protocols.
         [*The scope of NAT-PT should be restricted to IPv4-NAT compatible
applications.*]
  1.5  Inability to redirect packet fragments after the first with NAPT-PT.
         [*The scope of NAT-PT should be restricted to network paths and
applications which don't require fragmentation. This includes in particular
all network paths where PMTUs are large enough to support IPv6 packets (
1280 octets plus encapsulation headers not beyond 1500 octets), for all
applications over TCP and all applications UDP over UDP which don't impose
multi-fragment datagrams.*]
   1.6  Interaction with SCTP and multihoming.
         [*The scope of NAT-PT should be restricted to IPv4-NAT compatible
applications.*]
  1.7  Need for NAT-PT to act as proxy for correspondent node when IPv6 nod=
e
is mobile, with consequent restrictions on mobility.
        [*The scope of NAT-PT should be restricted to IPv4-NAT compatible
applications.*]
   1.8 NAT-PT not being able to handle multicast traffic.
        [*The scope of NAT-PT should be restricted to IPv4-NAT compatible
applications.*]

2. Issues which are exacerbated by the use of a DNS-ALG:

   2.1  Constraints on network topology.
        [*The constraint of a stable route through a single point can (and
should) be limited to connections which need NAT-PT, for which it is a must=
.
For this, parallel 6to4 relays which recognize destination addresses needin=
g
NAT-PT could redirect packets to the unique NAT_PT device. A scheme where
6to4 relays don't even need to be concerned
 is presented in http://perso.wanadoo.fr/remi.despres/4to6.htm .*]
   2.2  Scalability concerns together with introduction of single point of
failure and security attack nexus.
        [*NAT-PT servers can be implemented in server farms, with various a=
d
hoc load balancing (e.g. based on IPv6 source and IPv4 destination
addresses, or if ever needed even based on source and destination port
numbers).*]
  2.3.1  Lack of address mapping persistence: Some applications require
address retention between sessions.  The user traffic will be disrupted if =
a
different mapping is used.
        [*The scope of NAT-PT should be restricted to IPv4-NAT compatible
applications.*]
  2.3.2  The use of the DNS-ALG to create address mappings with limited
lifetimes means that applications must start using the address shortly afte=
r
mapping is created, as well as keeping it alive once they start using it.
       [*The scope of NAT-PT should be restricted to configurations which
don't need DNS ALG. Dual stack client hosts should be in charge of
converting IPv4 addresses they obtained in DNS A records into IPv6
addresses.  IPv4 mapped addreses can be converted this way, as well as  the
larger scope 4to6 addresses proposed in
http://perso.wanadoo.fr/remi.despres/4to6.htm ).*]
  2.4  Creation of a DOS threat relating to exhaustion of memory and
address/port pool resources on the translator.
       [*Such a threat exists but is a counterpart of reaching the
objective. It can be limited if server farms with load balancing are used,
and  various other existing DOS protection techniques may be used. Escaping
this threat will remain a motivation to upgrade IPv4 servers to IPv6
capability. *]

3. Issues which result from the use of a DNS-ALG (list not detailed here).
   [* The scope of NAT-PT should be restricted to configurations which don'=
t
need DNS ALG. *]

Regards,

R=E9mi Despr=E9s


----- Original Message -----=20
From: "Elwyn Davies" <elwynd@nortelnetworks.com>
To: <v6ops@ops.ietf.org>
Sent: Friday, November 05, 2004 7:55 PM
Subject: NAT-PT: To deprecate or not to deprecate: the question for next
week's v6ops discussion
...
> o Part of the point is that if we can live with these points in
> respect of NAT,
>         these are not necessarily reasons to deprecate NAT-PT.  NAT solve=
s
> an ongoing
>         problem in IPv4 whereas NAT-PT is intended to be a transition aid=
.
> On
>         the one hand we may feel it is easier to live with some issues if
> the mechanism
>         is not with us for ever, but on the other should we use a
mechanism
> that has
>         all these issues at all?
...
> Way forwards:
> - Tune the details
> - Show real examples, if any, where translators will really give better
> performance than proxies and are really vital. Make sure that backwards
> compatibility is fully considered, taking into account availability and
> migration of terminals from v4 to dual-stack/v6 plus the availability of
> tunnel support.
> - Either:
>    o Deprecate NAT-PT altogther and write other drafts with 'offspring of
> NAT-PT' to
>      cover the specialised use cases where a translator is useful, or
>    o Turn this into a new applicability draft recommending only a very
> limited set
>      of uses, and produce modifications to cater for some of the
specialised
> use cases.
...
> Elwyn
------=_Part_102015_24271624.1099932090491
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

SUMMARY<BR><BR>Some simple variant of NAT-PT, say NAT6,&nbsp; has to be ava=
ilable for IPv4 to<BR>IPv4 transition.<BR>To avoid unnecessary difficulties=
, its scope should be limited to:<BR>&nbsp; - Client hosts at IPv6-only add=
resses which call IPv4-only hosts<BR>&nbsp; - Client hosts which get their =
destination addresses by themselves (no<BR>need for DNS record translations=
 in NAT6).<BR>&nbsp; - IPv4 applications which are accessible via simple IP=
v4 NATs (no need for<BR>application level gateways in NAT6).<BR>&nbsp; - Ne=
twork paths which support at least 1280 octets packets (no need for<BR>frag=
mentation support in NAT6)<BR><BR><BR>ANALYSIS<BR><BR>&nbsp; KEY QUESTION 1=
 is:<BR>- Will&nbsp; IPv6 hosts having no global IPv4 address be able to re=
ach all IPv4<BR>servers and applications which IPv4 clients behind private =
NATs can reach?<BR>- A "yes" answer will clearly facilitate deployment of I=
Pv6 addresses.<BR>- Then some stateful address translation (some kind of NA=
T-PT) is<BR>unavoidable somewhere.<BR><BR>&nbsp;KEY QUESTION 2 is then:<BR>=
- Can IETF specify a workable solution? (Issues raised in<BR>"draft-aoun-v6=
ops-natpt-deprecate-00"&nbsp; have to be dealt with.)<BR><BR>&nbsp;ANSWER T=
O QUESTION 2<BR><BR>The following list of issues is that of<BR>"draft-aoun-=
v6ops-natpt-deprecate-00" , with approaches&nbsp; to resolve them<BR>betwee=
n brackets :<BR><BR>&nbsp;1. Issues which are independent of the use of a D=
NS-ALG:<BR><BR>&nbsp;&nbsp;&nbsp; 1.1 Disruption of all protocols which emb=
ed IP addresses (and/or&nbsp; ports)<BR>in packet payloads or which apply i=
ntegrity mechanisms using IP addresses<BR>(and ports).<BR>&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [*The scope of NAT-PT should be restr=
icted to IPv4-NAT compatible<BR>applications.*]<BR>&nbsp;&nbsp; 1.2 Inabili=
ty to re-direct traffic for protocols not built on top of<BR>specific trans=
port layer protocols in situations where one NAPT-PT is<BR>translating for =
multiple IPv6 hosts.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [*=
The scope of NAT-PT should be restricted to IPv4-NAT compatible<BR>applicat=
ions.*]<BR>&nbsp;&nbsp; 1.3&nbsp; Requirement for applications to use keep =
alive mechanisms to<BR>workaround connectivity issues caused by premature N=
AT-PT state timeout.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [*=
The scope of NAT-PT should be restricted to IPv4-NAT compatible<BR>applicat=
ions.*]<BR>&nbsp;&nbsp; 1.4&nbsp; Loss of information due to incompatible s=
emantics between IPv4 and<BR>IPv6 versions of headers and protocols.<BR>&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [*The scope of NAT-PT should =
be restricted to IPv4-NAT compatible<BR>applications.*]<BR>&nbsp; 1.5&nbsp;=
 Inability to redirect packet fragments after the first with NAPT-PT.<BR>&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [*The scope of NAT-PT should=
 be restricted to network paths and<BR>applications which don't require fra=
gmentation. This includes in particular<BR>all network paths where PMTUs ar=
e large enough to support IPv6 packets (<BR>1280 octets plus encapsulation =
headers not beyond 1500 octets), for all<BR>applications over TCP and all a=
pplications UDP over UDP which don't impose<BR>multi-fragment datagrams.*]<=
BR>&nbsp;&nbsp; 1.6&nbsp; Interaction with SCTP and multihoming.<BR>&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [*The scope of NAT-PT should be r=
estricted to IPv4-NAT compatible<BR>applications.*]<BR>&nbsp; 1.7&nbsp; Nee=
d for NAT-PT to act as proxy for correspondent node when IPv6 node<BR>is mo=
bile, with consequent restrictions on mobility.<BR>&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp; [*The scope of NAT-PT should be restricted to IPv4-NAT c=
ompatible<BR>applications.*]<BR>&nbsp;&nbsp; 1.8 NAT-PT not being able to h=
andle multicast traffic.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [*Th=
e scope of NAT-PT should be restricted to IPv4-NAT compatible<BR>applicatio=
ns.*]<BR><BR>2. Issues which are exacerbated by the use of a DNS-ALG:<BR><B=
R>&nbsp;&nbsp; 2.1&nbsp; Constraints on network topology.<BR>&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp; [*The constraint of a stable route through a s=
ingle point can (and<BR>should) be limited to connections which need NAT-PT=
, for which it is a must.<BR>For this, parallel 6to4 relays which recognize=
 destination addresses needing<BR>NAT-PT could redirect packets to the uniq=
ue NAT_PT device. A scheme where<BR>6to4 relays don't even need to be conce=
rned<BR>&nbsp;is presented in <A href=3D"http://perso.wanadoo.fr/remi.despr=
es/4to6.htm">http://perso.wanadoo.fr/remi.despres/4to6.htm</A> .*]<BR>&nbsp=
;&nbsp; 2.2&nbsp; Scalability concerns together with introduction of single=
 point of<BR>failure and security attack nexus.<BR>&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp; [*NAT-PT servers can be implemented in server farms, wit=
h various ad<BR>hoc load balancing (e.g. based on IPv6 source and IPv4 dest=
ination<BR>addresses, or if ever needed even based on source and destinatio=
n port<BR>numbers).*]<BR>&nbsp; 2.3.1&nbsp; Lack of address mapping persist=
ence: Some applications require<BR>address retention between sessions.&nbsp=
; The user traffic will be disrupted if a<BR>different mapping is used.<BR>=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [*The scope of NAT-PT should be =
restricted to IPv4-NAT compatible<BR>applications.*]<BR>&nbsp; 2.3.2&nbsp; =
The use of the DNS-ALG to create address mappings with limited<BR>lifetimes=
 means that applications must start using the address shortly after<BR>mapp=
ing is created, as well as keeping it alive once they start using it.<BR>&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [*The scope of NAT-PT should be restrict=
ed to configurations which<BR>don't need DNS ALG. Dual stack client hosts s=
hould be in charge of<BR>converting IPv4 addresses they obtained in DNS A r=
ecords into IPv6<BR>addresses.&nbsp; IPv4 mapped addreses can be converted =
this way, as well as&nbsp; the<BR>larger scope 4to6 addresses proposed in<B=
R><A href=3D"http://perso.wanadoo.fr/remi.despres/4to6.htm">http://perso.wa=
nadoo.fr/remi.despres/4to6.htm</A> ).*]<BR>&nbsp; 2.4&nbsp; Creation of a D=
OS threat relating to exhaustion of memory and<BR>address/port pool resourc=
es on the translator.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [*Such a thre=
at exists but is a counterpart of reaching the<BR>objective. It can be limi=
ted if server farms with load balancing are used,<BR>and&nbsp; various othe=
r existing DOS protection techniques may be used. Escaping<BR>this threat w=
ill remain a motivation to upgrade IPv4 servers to IPv6<BR>capability. *]<B=
R><BR>3. Issues which result from the use of a DNS-ALG (list not detailed h=
ere).<BR>&nbsp;&nbsp; [* The scope of NAT-PT should be restricted to config=
urations which don't<BR>need DNS ALG. *]<BR><BR>Regards,<BR><BR>R=E9mi Desp=
r=E9s<BR><BR><BR>----- Original Message ----- <BR>From: "Elwyn Davies" &lt;=
<A href=3D"mailto:elwynd@nortelnetworks.com">elwynd@nortelnetworks.com</A>&=
gt;<BR>To: &lt;<A href=3D"mailto:v6ops@ops.ietf.org">v6ops@ops.ietf.org</A>=
&gt;<BR>Sent: Friday, November 05, 2004 7:55 PM<BR>Subject: NAT-PT: To depr=
ecate or not to deprecate: the question for next<BR>week's v6ops discussion=
<BR>...<BR>&gt; o Part of the point is that if we can live with these point=
s in<BR>&gt; respect of NAT,<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; these are not necessarily reasons to deprecate NAT-PT.&nbsp; NAT =
solves<BR>&gt; an ongoing<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp; problem in IPv4 whereas NAT-PT is intended to be a transition aid.<B=
R>&gt; On<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the one h=
and we may feel it is easier to live with some issues if<BR>&gt; the mechan=
ism<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; is not with us =
for ever, but on the other should we use a<BR>mechanism<BR>&gt; that has<BR=
>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; all these issues at a=
ll?<BR>...<BR>&gt; Way forwards:<BR>&gt; - Tune the details<BR>&gt; - Show =
real examples, if any, where translators will really give better<BR>&gt; pe=
rformance than proxies and are really vital. Make sure that backwards<BR>&g=
t; compatibility is fully considered, taking into account availability and<=
BR>&gt; migration of terminals from v4 to dual-stack/v6 plus the availabili=
ty of<BR>&gt; tunnel support.<BR>&gt; - Either:<BR>&gt;&nbsp;&nbsp;&nbsp; o=
 Deprecate NAT-PT altogther and write other drafts with 'offspring of<BR>&g=
t; NAT-PT' to<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; cover the specialised u=
se cases where a translator is useful, or<BR>&gt;&nbsp;&nbsp;&nbsp; o Turn =
this into a new applicability draft recommending only a very<BR>&gt; limite=
d set<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; of uses, and produce modificati=
ons to cater for some of the<BR>specialised<BR>&gt; use cases.<BR>...<BR>&g=
t; Elwyn<BR><BR>
------=_Part_102015_24271624.1099932090491--




From owner-v6ops@ops.ietf.org  Mon Nov  8 11:47:49 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29528
	for <v6ops-archive@lists.ietf.org>; Mon, 8 Nov 2004 11:47:47 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CRCfc-000E4R-Rd
	for v6ops-data@psg.com; Mon, 08 Nov 2004 16:47:08 +0000
Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CRCfR-000E3O-AU
	for v6ops@ops.ietf.org; Mon, 08 Nov 2004 16:46:57 +0000
Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131])
	by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id iA8GkuGn020034
	for <v6ops@ops.ietf.org>; Mon, 8 Nov 2004 16:46:56 GMT
Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162])
	by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id QAA14008
	for <v6ops@ops.ietf.org>; Mon, 8 Nov 2004 16:46:53 GMT
Received: (from tjc@localhost)
	by login.ecs.soton.ac.uk (8.11.6/8.11.6) id iA8Gkrf05882
	for v6ops@ops.ietf.org; Mon, 8 Nov 2004 16:46:53 GMT
Date: Mon, 8 Nov 2004 16:46:53 +0000
From: Tim Chown <tjc@ecs.soton.ac.uk>
To: v6ops@ops.ietf.org
Subject: Re: Comments on draft-suryanarayanan-v6ops-zeroconf-reqs-00
Message-ID: <20041108164653.GH4373@login.ecs.soton.ac.uk>
Mail-Followup-To: v6ops@ops.ietf.org
References: <20041107234837.GH19316@login.ecs.soton.ac.uk> <00d901c4c555$51645b40$3a476c6b@sisodomain.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <00d901c4c555$51645b40$3a476c6b@sisodomain.com>
User-Agent: Mutt/1.4i
X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information
X-ECS-MailScanner: Found to be clean
X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

Thanks.

Having looked through the new draft, I don't think the generic points have 
been addressed, though some of the more minor ones may have been.

I guess we need some strategic discussion on the way forward on Wednesday,
as to how/if the documents combine and what solutions/timelines are
realistic/pragmatic.

Tim

On Mon, Nov 08, 2004 at 11:07:30AM +0530, Radhakrishnan Suryanarayanan wrote:
> Hi Tim,
>  Thanks a lot for your comments.
>  I will reply to your comments in detail ASAP. In the meantime, may i
> request you to look into the revision 01 for the draft
> 
> http://www.v6ops.euro6ix.net/ietf/draft-suryanarayanan-v6ops-zeroconf-reqs-01.txt
> 
> This draft is derived from non-registered mode discussed in the previous
> assisted tunneling requirements and partly from 3gpp-specific ZCT. Hence
> those identical chunks of text in places.
> 
> A reason for putting requirements under the scenario-specific is because of
> the need in some places
> related to making some of the requirements "must" or "should" from "should"
> or "may".
> 
> Nevertheless, there is lot of scope to improve the document and i shall try
> my best to do it. :)
> 
> >(In theory, draft-suryanarayanan-v6ops-zeroconf-reqs-00 could/should
> >list all the requirements, and each of the 4 scenario sections - 3gpp,
> >isp, unman, enterprise - should point at which requirements they carry?)
> Ideally a single draft should be sufficient.:)
> 
> >Will we thus see more simialr docs for unman, ent and isp?
> Definitely NOT. 3GPP is just one off case because of its timing
> requirements.
> 
> Thanks & Regards
> Radhakrishnan
> ----- Original Message ----- 
> From: "Tim Chown" <tjc@ecs.soton.ac.uk>
> To: <v6ops@ops.ietf.org>
> Sent: Monday, November 08, 2004 5:18 AM
> Subject: Comments on draft-suryanarayanan-v6ops-zeroconf-reqs-00
> 
> 
> > Hi,
> >
> > Some comments on this draft.   Overall I found it seemed overly long,
> > it meandered somewhat and lacked some focus, and included a number of
> > repeated chunks of text that could be saod in one place.
> >
> >
> >                Zero-Configuration Tunneling Requirements
> >             draft-suryanarayanan-v6ops-zeroconf-reqs-00.txt
> >
> >
> > >> Main comments:
> >
> > >> 1. Not clear what scope is, e.g. single node or not, within the
> >       network of a single provider or not, is host-host zct supported
> >       or not, etc.
> >
> > >> 2. Should state assumptions in one place/section, they are split
> >       across the document in many places.  This would include the
> >       two items in the "out of scope" appendix.
> >
> > >> 3. Should list all requirements in one section and have the four
> >       scenarios refer to that, at present some scenarios have their
> >       own (sometimes repeated) requirements.
> >
> > >> Specific comments:
> >
> > 1.  Introduction
> >
> >    One of the major differences between the zero-configuration tunneling
> >    mechanism and the full-fledged tunneling mechanism is that the former
> >    does not support user authentication, which should not be an issue
> >    because the scope of the users of this mechanism are already users of
> >    the Service Provider actually deploying it.  Consequently, the users
> >    are to be authenticated by other means, which are out of the scope of
> >    this document.
> >
> > >> Thus this zct solution is only for intra-provider solutions?  Just
> >    state that if it's the case.
> >
> > >> Is this a solution for single nodes only?  If so, state that clearly
> >    early on.
> >
> >    It should be emphasized that unless otherwise specified, in this
> >    document the reference, IPv6-in-IPv4 encapsulation as defined in [7],
> >    refers to the aspects of Protocol-41 encapsulation related to IPv4
> >    header construction (except for source and destination address
> >    determination), MTU and Fragmentation, Hop Limits and ICMP handling
> >    as detailed in Section 3.1-3.6 of [7].  The particular aspects of
> >    Configured IPv6-In-IPv4 Tunneling in the areas of IPv4 source and
> >    destination address determination, tunnel link characteristics and
> >    IPv6 Neighbor Discovery operation are not intended referred to by the
> >    above reference.
> >
> > >> This is a very clumsy paragraph.
> >
> >    This document only identifies requirements for a zero-configuration
> >    tunneling mechanism, based on which solutions can be developed or
> >    identified.
> >
> > >> Also misleading - do you mean the requirements are driven by the
> >    available solutions??   I assume not, so it needs rewording
> >
> > 2.  Terminology
> >
> >    Zero-Configuration Tunneling site: A logical IPv4 network over which
> >    IPv6 connectivity is provided to dual-stack nodes by means of
> >    Zero-Configuration Tunneling.
> >
> > >> Seems to also be a single-provider IPv4 network?
> >
> >    Tunnel End-Point (TEP): A dual-stack node performing IPv6-in-IPv4
> >    tunnel encapsulation/decapsulation in accordance with
> >    Zero-Configuration Tunneling.
> >
> > >> "in accordance with zct", but zct is not defined in this section?
> >
> >    Tunnel Server (TS): A dual-stack server node with IPv6 connectivity
> >    and which provides IPv6 connectivity to client nodes by performing
> >    IPv6-in-IPv4 tunnel encapsulation/decapsulation to/from client nodes
> >    in accordance with Zero-Configuration Tunneling.  A Tunnel Server is
> >    likely to be a dual-stack router.
> >
> > >> "with IPv4 and IPv6 connectivity"?
> >
> >    Direct Tunneling: Direct tunnelling here refer to the case where
> >    end-hosts located within the same Zero-Configuration Tunnelling site
> >    may circumvent the Tunnel Server and communicate directly using the
> >    tunnel protocol.
> >
> > >> Somewhere in this document do we need to comment on IPv4 compatible
> >    addressing, which is a form of zct?   These have been deprecated,
> >    but may (or may not!) be a solution to this requirement set?
> >
> > 3.  Applicability
> >
> >    Zero-Configuration Tunneling does not attempt to provide emulation of
> >    the full set of native IPv6 connectivity functions as defined by [8],
> >    [9] and [10]
> >
> > >> You're jumping into wider comments without yet saying what the zct
> >    should provide?   I think you should spell out what the requirements
> >    are first?  (Which is in Section 6, so maybe put this text there?)
> >
> >    It is possible that the same zero-configuration Tunneling mechanism
> >    can be used in various deployment scenarios.  However, it is not
> >    required that same tunnel set-up protocol be deployable in all
> >    scenarios.
> >
> > >> But we'd prefer one solution, so a node in different environments can
> >    use a single solution?
> >
> > 4.  Limitations
> >
> > 4.1  IPv6 address allocation, Scope and Limitations
> >
> >    It is not explicitly within the scope to support privacy extensions
> >    to IPv6 [11].
> >
> > >> Do you mean there is no requirement to support it?  If so, just say so.
> >
> >    It is not explicitly within the scope to support usage of IPv6
> >    multicast.
> >
> > >> Ditto.   (Though that is disappointing)
> >
> > 4.2  IPv6 tunnel link characteristics, Scope and Limitations
> >
> >    Direct tunneling is neither an explicit goal nor explicitly excluded
> >    in Zero-Configuration Tunneling.
> >
> > >> Ditto.
> >
> >    It is not an explicit requirement for the zero-configuration tunnel
> >    link to support IPv6 link-local multicast.
> >
> > >> Is that going to cause problems?  Perhaps clarify this.
> >
> >    The tunnel protocol should allow for the formation of a link-local
> >    address on the tunnel link, though no particular usage of such an
> >    address is explicitly demanded by the goals set forward here.
> >
> > >> Do you need the words after the ","?
> >
> > 5.  Basic Assumptions and Prerequistes
> >
> >    Zero-configuration Tunneling is a simple mode with no user
> >    registration, essentially deployed in a controlled and
> >    "authenticated" environment where the service is made available to
> >    all the IPv4 customers.
> >
> > >> s/essentially/typically?
> >
> >    o  The user is being authenticated to the network by means external
> >       to the tunneling protocol.
> >
> > >> But this solution can be used in open networks?  Or only authenticated
> >    access ones?
> >
> >    The following assumption is only valid for basic requirements where
> >    there is no NAT in the path.
> >
> >    o  The Zero-Configuration Tunneling network is fully penetrable for
> >       intra-site IPv6-in-IPv4 Protocol 41 traffic.
> >
> > >> Earlier you said "the tunnelling mechanism in [7]"... say that here or
> >    do you need to explictly specify proto-41?  (Just be consistent)
> >
> >    It is a prerequisite that the tunnel protocol must work in IPv4
> >    network environments where IPv4 multicast is not provided.
> >
> > 6.  Requirements for Zero-Configuration Tunneling Mechanisms
> >
> > 6.1  Basic Requirements
> >
> >    The basic requirements described below must be supported by any
> >    zero-configuration tunneling protocol.  Tunneling protocol satisfying
> >    these basic requirements could be used in a deployment scenarios
> >    which is NAT-free, does not require IPv6 /64 address or prefix
> >    delegation.
> >
> > >> The second sentence should be broken out into explicit assumptions
> >    or requirements.   Do you mean there should be no NATs between the
> >    client and tunnel server (or must not be)?   Do you mean the
> requirement
> >    is to only support /128 tunnels?   How does prefix delegation relate
> >    to a node-based mechanism?
> >
> > 6.1.1  Simplicity
> >
> >    The tunnel protocol is easy to implement in the targeted environment.
> >    Additionally, the protocol should provide a reasonable,limited set of
> >    basic IPv6 connectivity features
> >
> > >> What are these "reasonable, limited" features?
> >
> > 6.1.2  Automated IPv6-in-IPv4 tunnel establishment
> >
> >    The mechanism must be fully dynamic in the sense that it must not
> >    require IP address information such as the IPv4 address of a Tunnel
> >    Server and/or the IPv6 address(es) to use for IPv6 connectivity to be
> >    configured on the Tunnel Clients beforehand.
> >
> > >> So you mean automatic not dynamic?   If so, state that tunnel endpoint
> >    discovery is required, but is out of scope of this document.
> >
> > 6.1.3  IPv6 Address Assignment and Prefix Delegation
> >
> >    Prefix Delegation support is dealt with respect to various deployment
> >    scenarios in sections 6, 7, 8 and 9.  It is not however required that
> >    any tunneling protocol supporting only basic requirements provide
> >    support for prefix delegation.
> >
> > >> I'm not clear why you'd want to do prefix-delegation to a node?
> >    Or is zct to be applied to links as well?
> >
> >    It is preferable that the address assignment provides a stable
> >    address, that is, an address that can be used for IPv6 connectivity
> >    for a certain amount of time rather than solely one address per
> >    higher layer session initiation
> >
> > >> A bit clumsy, just delete text after the ","?
> >
> > >> Do you mean the same address on reconnection later?  If so, how do
> >    you do that without use of authentication, cookies or similar?
> >
> > 6.1.5  Tunnel Server End-Point Discovery
> >
> >    In order to offer "plug and play", the implementation should allow a
> >    mechanism to discover the address of the tunnel server that will
> >    provide the tunnel connectivity.  This discovery should be automatic
> >    within a Service Provider's network.
> >
> > >> Again state TEP discovery mechanism is outside the scope of this doc?
> >    Or is it not?  If you state it's required, a pointer to more info is
> >    needed.
> >
> > 6.1.7  Private and public IPv4 addresses
> >
> >    The tunnel protocol must work over IPv4 sites deploying both private
> >    and public IPv4 addresses.
> >
> >    Furthermore, the tunnel protocol should work with both dynamic and
> >    static IPv4 address allocation.
> >
> > >> What does this mean, in practice?  Do you mean the zct method should
> >    support the IPv4 address changing while the tunnel is up??   If you
> >    mean to get the same IPv6 address when reconnecting on a new IPv4
> >    dynamic address on a new session, how do you do that without any
> >    authentication?
> >
> > 6.1.8  Scalability and Load-Balancing
> >
> >    This may be achieved using load balancing functions provided by the
> >    Tunnel Server End-point Discovery mechanism as detailed in [13].
> >
> > >> So now you add a pointer to the TEP text; this is needed earlier also.
> >
> > 6.1.9  Easy to deploy and Easy to Phase Out
> >
> >    Once IPv6 is available natively in the access network, it should be
> >    easy to phase out the tunneling protocol.
> >
> > >> Two subtle different meanings to "should" here... :)
> >
> > 6.2.1  Tunnel Link Sustainability
> >
> >    In certain environments, like in 3GPP, to minimize the overhead and
> >    latency associated with tunnel initialisation, it is highly desirable
> >    that tunnels remain active for a large amount of time, ideally
> >    infinitely.  In such environments, the tunnel protocol must not
> >    mandate keep-alive messages to be transmitted by the host simply in
> >    order to sustain tunnel link connectivity.
> >
> > >> Presumably in a no-NAT environment such keep-alives are not so
> >    necessary.   Some tunnel brokers use heartbeats to allow reconnection
> >    with the same (address) parameters.  Maybe that's beyond zct scope.
> >
> > 6.2.2  NAT Traversal
> >
> >    The Tunnel set-up protocol must be able detect the presence of one or
> >    more NATs in its path.  It must be able to adapt to the following
> >    cases, by choosing the most optimal tunnel encapsulation depending on
> >    the presence of a NAT.
> >
> > >> But above you said no-NAT environments?  Which is it?
> >
> > >> Are you saying NAT traversal must be supported?
> >
> > 6.2.3  Firewall Traversal
> >
> >    Even if no NAT is in the tunnel path, there may be a firewall which
> >    prohibits proto-41.  In such case, the tunnel encapsulation selection
> >    based on NAT detection will select a tunnel that will not work.
> >
> > >> Doesn't that depend on the specifics of the detection mechanism?
> >
> >    The implementation must allow a user to explicitly specify the
> >    desired tunnel encapsulation, regardless of the NAT detection
> >    process.
> >
> > 6.2.4  Extensibility
> >
> >    The protocol must be extensible to support tunnel encapsulation other
> >    than IPv6 in IPv4 and IPv6 in transport in IPv4.  In particular,
> >    encapsulation of IPv4 in IPv6 or IPv6 in IPv6 could be defined.
> >
> > >> "must be" or "could be" - decide :)
> >
> > 6.2.5  IPv6 Address Stability
> >
> >    [This section shall be removed after getting more opinions from
> >    others.]
> >
> >    The IPv6 address is "transient" and may change, but the protocol
> >    should offer a mechanism to provide IPv6 address stability (e.g.
> >    cookie mechanism).  The implementation of this mechanism must allow
> >    this feature to be turned off.
> >
> > >> You already mentioned this earlier.  Just do it in one place?
> >
> > 8.  Unmanaged Networks Specific Requirements
> >
> >    An unmanaged network is where no network manager or staff is
> >    available to configure network devices.
> >
> > >> No need to state what it is, just cite the unman-scenario text,
> >    which you do just below, so delete this.
> >
> >    Zero-Configuration Tunneling
> >    Protocol is quite useful in this context where automation of IPv6
> >    connectivity to first-hop ISP and prefix assignment is handled.
> >
> >    Unmanaged Networks [3] may or may not be behind a NAT.
> >
> >    A zero-configuration tunneling mechanism should satisfy the basic
> >    requirements (see section 6.1) and should take into account the
> >    specific requirements described below.
> >
> > 8.1  Address Assignment and Prefix Delegation
> >
> >    In unmanaged networks, assignment of an IPv6 address (/64) to the
> >    end-node must be supported.
> >
> > >> OK, so it isn't a node-based mechanism.   Get the text at the start :)
> >
> > 8.2  NAT Traversal
> >
> >    The implementation must provide an option to to turn on extra
> >    encapsulation manually.In order to assure interoperability, at least
> >    one common tunnel encapsulation type must be supported.
> >
> > >> Are you going to name one?
> >
> > 8.3  Firewall Traversal
> >
> >    As indicated in section 6.2.3, the tunneling protocol must be able to
> >    work in networks where the firewall prohibits proto-41 packets.
> >
> > >> But firewalls implement policy, and won;t that policy prevent other
> >    types of tunnelling?
> >
> > 9.  Enterprise Network Requirements
> >
> >    In an enterprise network where IPv4 is dominant, a tunneled
> >    infrastructure can be used to provider IPv6 services to the IPv6
> >    islands (hosts or networks) inside the enterprise, before a full IPv6
> >    native infrastructure is built.  Zero-Configuration tunneling
> >    protocol can be used to give IPv6 connectivity and prefix information
> >    for the islands.  This gives to the enterprise a basic deployment of
> >    IPv6 while maintaining automation and permanence of the IPv6
> >    assignments to the islands.
> >
> > >> Isn't this unlikely?  Wouldn't the network administrators prefer a
> >    structured and managed deployment method?
> >
> >    In cases where the network administrator is sure about the absence of
> >    internal NAT and firewalls in the network, and end-nodes will need
> >    only IPv6 /128 address, a tunneling protocol satisfying only the
> >    basic requirements will suffice.
> >
> > >> And there's no need for IPv6 address stability, or extensibility in
> >    the network (to be consistent with 6.2)
> >
> >    A zero-configuration tunneling mechanism should satisfy the basic
> >    requirements (see section 6.1) and should take into account the
> >    specific requirements described below.
> >
> > >> Why are they below and not just in section 6??   The requirements
> >    are being repeated in the scenario sections, bloating the text.
> >
> > 9.4.1  IPv4-in-IPv6 Tunneling
> >
> >    The tunneling Protocol should be able to handle automatic
> >    establishment of IPv4-in-IPv6 tunnels.  It must be able to handle
> >    assignment of temporary IPv4 address and other tunnel parameters as
> >    required.
> >
> > >> This is a new one, and only suggested higher up in the doc, I
> >    would cite it as an advanced requirement?
> >
> > 10.  ISP Network Specific Requirements
> >
> >    In a scenario where connection to customer from ISP supports both
> >    IPv4 and IPv6, but the customer has IPv6-only network and the ISP
> >    backbone is IPv4-only, IPv6 packets from customer needs to be
> >    tunneled over the IPv4 backbone to the next upstream ISP.
> >    Zero-configuration tunneling mechanism can be used in such scenario
> >    as well.
> >
> > >> So it's being used for a whole network here, not a node?
> >
> >
> >

-- 
Tim

North American IPv6 Task Force Technologist Seminar
More info at http://www.ipv6seminar.com/



From owner-v6ops@ops.ietf.org  Mon Nov  8 13:24:21 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09456
	for <v6ops-archive@lists.ietf.org>; Mon, 8 Nov 2004 13:24:21 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CREA9-000Ods-Kc
	for v6ops-data@psg.com; Mon, 08 Nov 2004 18:22:45 +0000
Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CREA8-000Odd-JN
	for v6ops@ops.ietf.org; Mon, 08 Nov 2004 18:22:44 +0000
Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131])
	by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id iA8IMhGn022532
	for <v6ops@ops.ietf.org>; Mon, 8 Nov 2004 18:22:43 GMT
Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162])
	by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id SAA18625
	for <v6ops@ops.ietf.org>; Mon, 8 Nov 2004 18:22:41 GMT
Received: (from tjc@localhost)
	by login.ecs.soton.ac.uk (8.11.6/8.11.6) id iA8IMf708289
	for v6ops@ops.ietf.org; Mon, 8 Nov 2004 18:22:41 GMT
Date: Mon, 8 Nov 2004 18:22:41 +0000
From: Tim Chown <tjc@ecs.soton.ac.uk>
To: v6ops@ops.ietf.org
Subject: Comments on draft-aoun-v6ops-natpt-deprecate-00
Message-ID: <20041108182241.GO4373@login.ecs.soton.ac.uk>
Mail-Followup-To: v6ops@ops.ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4i
X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information
X-ECS-MailScanner: Found to be clean
X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

Hi,

I think this draft is a very good summary of the NAT-PT issues, and thus 
we are at a stage where we can discuss what action to take based on the
limitations of NAT-PT as described in the document.   

The key argument for proponents of NAT-PT seems to be that there are valid
"last resort" corner cases for which NAT-PT is the only solution.  It 
would be interesting to see a "usage of NAT-PT" text to make a case for
the defence, so to speak.  Interaction with legacy hardware is one example
of such a corner case.

Minor suggestions for the draft:

- I think the issues in Section 5 should be emphasised more strongly,
  and I recall others have expressed this view on the list.

- Privacy addresses might add an extra complexity for NAT-PT, if each
  node may have a number of active privacy addresses, and may need 
  to still receive communications to non-current privacy addresses that
  have been used in the past, e.g. where the node generates a new 
  privacy address each 24 hours, but still listens on "past" addresses.o
  (I think the NAT-PT + RFC3041 issues need to be thought out, and
  included in this text.)

- Also cite RFC2993 (Architectural NAT Issues) ?

- The NAT-PT issue list is interesting in that it can also be used to
  measure transport or application layer proxying limitations (which
  may also differ in aspects such as raw performance/throughput, but
  that I think is not in scope here).   Some issues are generic with
  any layer translation, e.g. single point of failure.

- There has been some usage of NAT-PT back-to-back to connect IPv6
  only islands across IPv4 only networks.

- A typo "appplied" in the Introduction

Cheers,
-- 
Tim



From owner-v6ops@ops.ietf.org  Mon Nov  8 13:24:35 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09488
	for <v6ops-archive@lists.ietf.org>; Mon, 8 Nov 2004 13:24:34 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CREB8-000Ohn-Qn
	for v6ops-data@psg.com; Mon, 08 Nov 2004 18:23:46 +0000
Received: from [209.71.226.4] (helo=ex.hexago.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CREB7-000OhW-MK
	for v6ops@ops.ietf.org; Mon, 08 Nov 2004 18:23:45 +0000
Received: from [130.129.133.2] ([130.129.133.2])
	by ex.hexago.com ( hexago/8.12.9) with ESMTP id iA8INstb005887;
	Mon, 8 Nov 2004 13:23:55 -0500 (EST)
	(envelope-from Florent.Parent@hexago.com)
Date: Mon, 08 Nov 2004 13:25:43 -0500
From: Florent Parent <Florent.Parent@hexago.com>
To: Tim Chown <tjc@ecs.soton.ac.uk>, v6ops@ops.ietf.org
Subject: Re: Comments on draft-ietf-v6ops-assisted-tunneling-requirements-01
Message-ID: <C5BECDD5A6B37F52EC58885A@[192.168.31.2]>
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-3.6 required=5.0 tests=AWL,BAYES_00,SUBJ_HAS_UNIQ_ID 
	autolearn=no version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit



-- On Monday, November 08, 2004 00:31:17 +0000, Tim Chown wrote:

> Hi,
>
> Commenst on this draft are less numerous.   I think it reads better, and
> is much more nicely focused.
>
> The open question seems to be the relationship between this and ZCT, esp.
> since this has identical chunks of text in places to ZCT :)
>
>
>                 Goals for Registered Assisted Tunneling
>           draft-ietf-v6ops-assisted-tunneling-requirements-01
>
>
>>> There is a lot of overlap with ZCT; should these documents be
>    merged and authentication/TSP be made an extra requirement?
>    i.e. should we have one solution that has authentication/TSP
>    options, or two separate solutions?  (Or does that not matter?)
>    We should also be clear about the applicability to nodes and/or
>    networks by ZCT and this work.
>
>>> (there is a fair amount of text in here cut and pasted from ZCT)

Yes, there is. What happened is that we decided to move the non-registered 
assisted tunneling into the new "generic" zero-conf draft. Overlap is 
difficult to avoid.

>
> 1.  Goal and Scope of the Document
>
>
>    "Assisted tunneling" is used in this document to describe a
>    transition mechanism where the parameters to configure a
>    bi-directional tunnel between an end-node (or leaf network) and a
>    router in the core of an ISP are exchanged through a tunnel set-up
>    protocol.  Although this exchange can be automated, this remains
>    different from transition mechanisms like 6to4, Teredo or ISATAP.  In
>    particular, assisted tunneling enables explicit access control to the
>    tunneled IPv6 connectivity, where the other transion mechanisms have
>    to rely on other kinds of control (e.g., access control based on the
>    IPv4 address).  Also, assisted tunneling protocol negotiate the
>    tunnel parameters and does not depend on having the IPv4 address
>    inside the IPv6 address, for example.
>
>>> It should be clearer what the difference between this draft and the
>    ZCT draft is.  From the intro text, it seems to be the use of a
>    tunnel setup protocol, and thus the possibility of authentication
>    of users.

The basic difference is authentication prior establishing the tunnel. Will 
add that in this section.

>
>>> As per ZCT, does this draft apply to nodes or networks too?

yes.

>
>
> 2.  Applicability
>
>    o  The customer configuration may be diverse, and not necessarily
>       predictable by the ISP.  The protocol must be able to adapt to the
>       following cases, for example by choosing the most optimal tunnel
>       encapsulation depending on the presence of a NAT.
>
>       *  a single node,
>       *  a leaf network,
>       *  using a globally routable IPv4 address,
>       *  behind a NAT (customer or ISP owned),
>       *  using dynamic IPv4 address (internally or externally to the
>          NAT)
>
>>> So it is nodes and networks.  I think that's good for assisted
>    tunnelling, but ZCT should probably be nodes only?   Is this a
>    distinction to draw (assuming we keep the texts separate)?

ZCT as support for prefix delegation too. As stated above, the difference 
is really authentication.

>
>>> The NAT and dynamic IPv4 address support should be requirements?

Yes. Do you think they should not?

>
>    There are actually two cases where the IPv4 address of the customer
>    tunnel end point can be dynamic, and both must be supported:
>
>    o  The device used as tunnel end point is using a dynamic IPv4
>       address provided by the ISP.
>
>    o  The device used as tunnel end point is located behind a customer
>       owned NAT box that is also acting as a local DHCP server.  In that
>       case, the device IPv4 address may change after a reboot.
>
>>> This text is copied from the ZCT draft... how much else is copied?
>    (Just curious)

Actually copied from assisted-tunneling. Again, overlap is hard to avoid.

>
>    In the enterprise scenario [I-D.ietf-v6ops-ent-analysis], assisted
>    tunneling can be used to support remote users connecting to the
>    enterprise network (section 7.5.2).
>
>>> Or to connect IPv6 islands inside the network?  (I'm not convinced
>    it should be, but it could be)

Good point. Will add.

>
> 3.  Requirements for Simplicity
>
>    This protocol is a transition mechanism, thus does not need to be
>    perfect.  As a matter of fact, making it perfect would be counter
>    productive, at it would first delay its definition, then make its
>    deployment more cumbersome and, last but not least, diminish the
>    incentives to deploy native IPv6.
>
>>> I think this paragraph should be deleted.

Ok. Anyone object?

>
> 4.  Protocol Requirements
>
>    o  stay in touch with users
>
>>> And per-user accounting? (and users might like to see their v6 usage
>>>
>    too?)

already mentionned in 4.8 (accounting)

>
> 4.4  Confidentiality
>
>    Protecting the tunneled data (IPv6 in this case) should be possible.
>    A possible usage scenario is when an enterprise's users is working
>    off-site and tunneling to the enterprise network (7.5.2
>    [I-D.ietf-v6ops-ent-analysis]).  Mechanisms do exist to make this
>    possible, such as using IPsec over IPv6 [RFC2401].
>    [I-D.tschofenig-v6ops-secure-tunnels] may be applicable here but is
>    not analysed further.
>
>>> Users may also VPN home with v4 and then tunnel; this kind of
>    approach is being used (e.g. with OpenVPN).   It's an interesting
>    question as to which approach is "better".

If you have a v4 VPN, a zero-conf approach can also be used.

>
> 4.5  Service Discovery
>
>    In order to facilitate deployment, the implementation should allow a
>    mechanism to discover the address of the server that will provide the
>    tunnel connectivity.
>
>    This discovery should be automatic when the protocol is used within
>    an ISP network.  There is no service discovery requirements when used
>    outside the provider network (roaming users, 3rd party ISP).
>
>>> But if I'm at the IETF, outside my university/ISP network, I really do
>    want to discover a tunnel end point automatically...?

Yes, which is why its written "no service discovery requirements when used 
outside the provider network".

>
>    Tunnel end-point discovery mechanism work
>    ([I-D.palet-v6ops-tun-auto-disc] may be applicable here.
>
>>> You mean "is" not "may be"?

ok.

>
> 4.6  NAT Traversal
>
>    NAT traversal is identified as a requirement in ISP scenarios
>    (section 5.1 [I-D.ietf-v6ops-isp-scenarios-analysis]) and unmanaged
>    scanarios (section 7, Recommendation 1 [RFC3904])
>
> 4.7  Firewall Traversal
>
>    Even if no NAT is in the tunnel path, there may be a firewall which
>    prohibits IP protocol 41.  In such case, the tunnel encapsulation
>    selection based on NAT detection (Section 5.2) will select a tunnel
>    that will not work.
>
>>> Another example of text cut and pasted from ZCT...
>
> 5.7  Extensibility
>
>    The protocol must be extensible to support tunnel encapsulation other
>    than IPv6 over IPv4 and IPv6 over transport over IPv4.  In
>    particular, encapsulation of IPv4 over IPv6 (section 7
>    [I-D.ietf-v6ops-isp-scenarios-analysis], section 7 [RFC3904], section
>    6 [I-D.ietf-v6ops-ent-analysis]) or IPv6 over IPv6 could be defined.
>
>>> The "must" is strong, but I would agree with it, if we want a
>    single mechanism to be applicable in the longer term.  But this is
>    likely to be contentious... :)

Ok. This can be moved to a should. But I would like to have other feedback

>
> 6.  Compatibility with other Transition Mechanisms
>
>    The tunnel set-up protocol is not required to be compatible with any
>    existing transition mechanism.  Although, a great deal of experience
>    can be drawn from the operation of tunnel brokers currently using the
>    TSP protocol [I-D.blanchet-v6ops-tunnelbroker-tsp].
>
>>> But are various TSPs compatible / interoperable with each other?

"various TSPs" = independent implementations?

Thanks Tim.

Florent





From owner-v6ops@ops.ietf.org  Mon Nov  8 13:33:12 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10402
	for <v6ops-archive@lists.ietf.org>; Mon, 8 Nov 2004 13:33:11 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CREJr-000PdU-FN
	for v6ops-data@psg.com; Mon, 08 Nov 2004 18:32:47 +0000
Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CREJq-000Pd5-2R
	for v6ops@ops.ietf.org; Mon, 08 Nov 2004 18:32:46 +0000
Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131])
	by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id iA8IWjGn022664
	for <v6ops@ops.ietf.org>; Mon, 8 Nov 2004 18:32:45 GMT
Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162])
	by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id SAA18978
	for <v6ops@ops.ietf.org>; Mon, 8 Nov 2004 18:32:40 GMT
Received: (from tjc@localhost)
	by login.ecs.soton.ac.uk (8.11.6/8.11.6) id iA8IWep08677
	for v6ops@ops.ietf.org; Mon, 8 Nov 2004 18:32:40 GMT
Date: Mon, 8 Nov 2004 18:32:40 +0000
From: Tim Chown <tjc@ecs.soton.ac.uk>
To: v6ops@ops.ietf.org
Subject: Re: Comments on draft-ietf-v6ops-assisted-tunneling-requirements-01
Message-ID: <20041108183240.GR4373@login.ecs.soton.ac.uk>
Mail-Followup-To: v6ops@ops.ietf.org
References: <C5BECDD5A6B37F52EC58885A@[192.168.31.2]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <C5BECDD5A6B37F52EC58885A@[192.168.31.2]>
User-Agent: Mutt/1.4i
X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information
X-ECS-MailScanner: Found to be clean
X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-3.5 required=5.0 tests=AWL,BAYES_00,SUBJ_HAS_UNIQ_ID 
	autolearn=no version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

Hi Florent,

A couple of comments on comments.

On Mon, Nov 08, 2004 at 01:25:43PM -0500, Florent Parent wrote:
> >
> >>>As per ZCT, does this draft apply to nodes or networks too?
> 
> yes.

OK, I was just wondering if we wanted a quite lightweight solution whether
is should apply to nodes and/or networks.  If there is a distinction, then
it seems your work should handle both, while (the lighterweight) ZCT does 
nodes only.  But if we do end up with some (re)merger the generic solution 
should handle both.

> >>>The NAT and dynamic IPv4 address support should be requirements?
> 
> Yes. Do you think they should not?

I think they are certainly desirable :)   In ZCT, not so sure (since ZCT is
an intra-provider requirement, it seems).
 
> >   This discovery should be automatic when the protocol is used within
> >   an ISP network.  There is no service discovery requirements when used
> >   outside the provider network (roaming users, 3rd party ISP).
> >
> >>>But if I'm at the IETF, outside my university/ISP network, I really do
> >   want to discover a tunnel end point automatically...?
> 
> Yes, which is why its written "no service discovery requirements when used 
> outside the provider network".

I guess I read it differently... as a user I would like automatic discovery
wherever I am; I think you are writing from the provider perspective?
 
> >6.  Compatibility with other Transition Mechanisms
> >
> >   The tunnel set-up protocol is not required to be compatible with any
> >   existing transition mechanism.  Although, a great deal of experience
> >   can be drawn from the operation of tunnel brokers currently using the
> >   TSP protocol [I-D.blanchet-v6ops-tunnelbroker-tsp].
> >
> >>>But are various TSPs compatible / interoperable with each other?
> 
> "various TSPs" = independent implementations?

How many TSP implementations are there? :)

Tim



From owner-v6ops@ops.ietf.org  Mon Nov  8 14:48:54 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20454
	for <v6ops-archive@lists.ietf.org>; Mon, 8 Nov 2004 14:48:54 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CRFTh-0007c3-Mk
	for v6ops-data@psg.com; Mon, 08 Nov 2004 19:47:01 +0000
Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CRFTg-0007bj-9n
	for v6ops@ops.ietf.org; Mon, 08 Nov 2004 19:47:00 +0000
Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131])
	by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id iA8JkxGn024218
	for <v6ops@ops.ietf.org>; Mon, 8 Nov 2004 19:46:59 GMT
Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162])
	by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id TAA20650
	for <v6ops@ops.ietf.org>; Mon, 8 Nov 2004 19:46:55 GMT
Received: (from tjc@localhost)
	by login.ecs.soton.ac.uk (8.11.6/8.11.6) id iA8Jkt310100
	for v6ops@ops.ietf.org; Mon, 8 Nov 2004 19:46:55 GMT
Date: Mon, 8 Nov 2004 19:46:55 +0000
From: Tim Chown <tjc@ecs.soton.ac.uk>
To: v6ops@ops.ietf.org
Subject: Comments on draft-palet-v6ops-tun-auto-disc-02
Message-ID: <20041108194655.GD9395@login.ecs.soton.ac.uk>
Mail-Followup-To: v6ops@ops.ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4i
X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information
X-ECS-MailScanner: Found to be clean
X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk


A good document.

- I think requirements could be spun out to a separate section.

- I think reverse DNS method(s) should be considered.

- Intra-enterprise could be a 5th scenario.



         Analysis of IPv6 Tunnel End-point Discovery Mechanisms
                 draft-palet-v6ops-tun-auto-disc-02.txt


   Tunneling is commonly used in several IPv6 transition mechanisms.  To
   be able to automate setting up tunnels, one critical component is
   being able to automatically determine the tunnel end-point for the
   tunneling mechanism.  This memo analyses the different approaches for
   configuring the IPv6 tunnel endpoint on a node.

>> To be pedantic it is methods to determine the remote IPv4 address of
   the tunnel?

1.  Introduction

   One critical piece in the automated set-up is discovering the
   end-point for the IPv6-in-IPv4 (or possibly in the future,
   IPv4-in-IPv6) tunnel.  Note that the other end-point ("tunnel
   server") typically also needs to have a means to configure the
   client's end-point, but that is assumed to be transition mechanism
   specific, and beyond the scope of this memo.  A solution is being
   designed [1] based on the tunnel server/broker concept [2] which
   will, in particular, require this kind of discovery.

>> Should you mention such solutions in this document?

   Many already-specified mechanisms already include a form of
   auto-discovery: for example, 6to4 [3] uses global anycast [4] and/or
   vendor's branch of DNS, Teredo [5] uses vendor's branch of DNS, and
   ISATAP [6] uses search-path -prefixed DNS.

>> You should probably use a clearer phrase than "vendor's branch of 
   DNS" here.

2.1  Scenario 1: Initial IPv6 Deployment Stage

   If this kind of IPv6 connectivity is set up automatically, it could
   create a load on the ISP's equipment which is configured as the
   tunnel-endpoint (e.g., a tunnel server).  This is particularly
   important if state needs to be maintained.  To address this
   consideration, the discovery method should allow for multiple
   end-points within a domain or even including a load-balancing
   mechanism.

>> Should such requirements be split into a separate section?

2.2  Scenario 2: Initial IPv6 Support from External ISP

   Given the fact that IPv6 service could be offered by third parties,
   some kind of authentication could be required in order to allow only
   registered customers to use the IPv6 service.  The authentication
   method will depend on the transition mechanism, so it is out of scope
   of this memo.

>> But it is another (optional) requirement to split off (or at least
   summarise in a subsequent section).


2.3  Scenario 3: Nomadic Users


   Nomadic users require connectivity to Internet from everywhere, from
   different locations: meetings, conferences, holidays, etc.  Under
   this circumstance (always) obtaining native IPv6 connectivity is not
   feasible.  The user has two choices: to discover a local tunnel (with
   different IPv6 addresses and prefixes) if provided by the local ISP,
   or to connect to the "home ISP" or "home network", implying the
   possibility of keeping the same addresses.

>> I'm not clear that nomadic users should be any different from case
   2.2 (the 3rd part ISP)?
 
   A local tunnel is typically a preferable choice, and could also be
   used as a Mobile IPv6 [7] care-of address.  However, in many cases,
   the local ISP may not be providing a tunnel service.

>> No need to mention MIPv6 here, just delete that?

   Connecting to a "home provider" to obtain the tunnel is typically a
   safe choice, provided that the "home provider" allows IPv4 addresses
   outside its own domain to use its tunnel services; at the very least,
   typically this will require some sort of authentication.  However,
   especially when roaming on a different continent as the home network,
   the latencies, etc., may be undesirable, so one might want to keep
   this only as a backup option in case other approaches fail.

>> Minimising latency may be another requirement to split out.

   The whole process for having a new IPv6 tunnel with a new provider
   should be as transparent as possible in order to avoid that users
   need to manually re-register or change the configuration in their
   host.  It would be desirable that the architecture enables the users
   to get connected and re-connected to the nearest tunnel end-point
   without manual intervention (for example when moving).

>> As is transparency in the mechanism (but that may be hard if explicit
   authentication is needed).

2.4  Scenario 4: Advanced IPv6 Deployment Stage

   When the IPv6 deployment is in a more advanced stage, namely more
   users in more places looking for IPv6 connectivity, it is possible
   that ISPs providing IPv6 connectivity need to start a broader
   deployment.  For a best IPv6 service, it is feasible that they
   increase the performance by using a tunnel end-point cluster
   geographically distributed to cover a country, etc.  Furthermore they
   could offer the users only one of the methods proposed below for
   accessing the IPv6 connectivity.  Each time users get IPv6
   connectivity, they could use the same accessing method but they could
   be assigned to different tunnel end-point belonging the cluster.

>> Isn't this just restating the laod-balancing requirement? 

   Under this schema, some kind of load balancing could be required in
   order to distribute the load among the ISP resources.

>> Aha yes it is :)

   In order to let all the candidate tunnel end-points to know the
   configuration of the previous user's tunnels, some kind of tunnel
   management should be defined.  However it is strongly dependant on
   the transition mechanism used, so it is out of the scope of this
   document.

>> But it is a requirement to note.   Identifying users is also useful
   e.g. in the case of heartbeat protocols that detect when the same
   user reconnects with a different (e.g. dynamic on their SOHO DSL
   network) IPv4 endpoint address.

>> So in fact there are now four scenarios, not the three you stated at
   the start of this section?

>> Is there a case also for TEP discovery in intra-site sparse IPv6 
   (dual-stack) deployment also in the enterprise?  (e.g. that which is 
   currently done by some by isatap and the isatap router)

3.2  Centralized Broker-based Solutions

   The selection of the proper TEP would be based on information about
   TEP loads and network metrics collected by several ways, such as RTTs
   measured by network probes, routing protocol information, and so
   forth. 

>> These are more requirements to split out/ add to the requirements 
   summary?

   The user will need to connect to the selected TEP either by
   using the DNS system, when the client tries to resolve the host name,
   or by mean of whatever other mechanism defined, which possibly will
   require an specific code implementation on both centralized server
   and clients.

>> So this is similar to how a web servers may be geographically
   distributed?

   3.  It can require the installation of specific software on both
       centralized server and clients to negotiate the proper TEP.

>> But you need specific software anyway for the authentication on TSP,
   if you use TSP?

   Therefore, when evaluating the solutions, it will be important to be
   able to contrast the real benefits of the solution vs the drawbacks.

>> Are you doing this? :)

3.3  DNS-based Solutions

   1.  "global name": the systems look up a globally unique name, like
       www.tunnel-server.net.; this could be applicable with
       (unfeasible) global inter-domain broker or anycast-based
       solutions, and is therefore not considered at more length.

>> You also mentioned this above too in 3.2?

   3.  "prefixing the search path" [10]: one could look up a
       service-specific special string, like "_tunnel-server", appended
       by the DNS search path, e.g., "isp.example.com", resulting in a
       query of "_tunnel-server.isp.example.com".  This assumes that the
       DNS search path is provided by the ISP, and used by the user;
       this applies to most users (advanced users may have their own
       domain names, own DNS servers, etc., but those could be expected
       to manually configure the end-point information).  This is the
       most interesting approach, explored at more length below.

>> I share Alain's concerns on this.

3.3.1  Prefixing the DNS Search Path

   Another consideration is the deployment of wildcard DNS records.  If
   A/AAAA records were to be used, such records might create false
   positives quite easily.  Fortunately, wildcards are commonly deployed
   only for MX records.  A benefit of using SRV records is that they use
   an additional level in the zones, like:
   _tunnel-server._udp.isp.example.com."; this would prevent a wildcard
   record "*.isp.example.com" from harassing the discovery of the
   end-point.  XXX: needs to be checked.

>> Has this been confirmed either way?

3.4  DHCP-based Solutions

   o  It requires manual configuration/update of the ISP's DHCP servers
      when there are changes to the tunnel end-points, similar to
      updating DNS, NTP, etc., servers.

>> But this is true of any method?

>> There seems to be more detail on SLP than other methods?   Should
   this level of detail be balanced?

>> What about reverse DNS methods?






From owner-v6ops@ops.ietf.org  Mon Nov  8 15:33:07 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26849
	for <v6ops-archive@lists.ietf.org>; Mon, 8 Nov 2004 15:33:07 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CRGBa-000Cxs-3X
	for v6ops-data@psg.com; Mon, 08 Nov 2004 20:32:22 +0000
Received: from [66.15.163.216] (helo=tndh.net)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CRGBY-000CxJ-V4
	for v6ops@ops.ietf.org; Mon, 08 Nov 2004 20:32:21 +0000
Received: from eaglet (127.0.0.1:4311)
	by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server]
	id <S7B63E> for <v6ops@ops.ietf.org> from <alh-ietf@tndh.net>;
	Mon, 8 Nov 2004 12:32:15 -0800
From: "Tony Hain" <alh-ietf@tndh.net>
To: "'EricLKlein'" <ericlklein@softhome.net>, <v6ops@ops.ietf.org>
Subject: RE: NAT-PT: To deprecate or not to deprecate: the question for  next w eek's v6ops discussion
Date: Mon, 8 Nov 2004 12:32:12 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-Reply-To: <001601c4c3d9$d469a770$0401a8c0@ttitelecom.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcTD2ucO3LEkK+JXQrC0bMaY8VxJTgBPlkNQ
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Message-Id: <E1CRGBa-000Cxs-3X@psg.com>
Content-Transfer-Encoding: 7bit

FWIW: like it or not we need a function that deals with IPv6-only devices
talking to IPv4-only legacy devices. That is the useful function of NAT-PT
and it works as well as IPv4-IPv4 nat as long as it is parked as close to
the IPv4-only device as possible. The DNS-ALG shouldn't be there because it
decreases the overall network value by confusing the IPv6 device. As such
the deprecate NAT-PT / NAT-PTbis effort needs to simply focus on removing
the DNS cruft. 

Legislating how people run their networks is not the job of the IETF.
Documenting how to get their job done efficiently is something the IETF can
and should do as creator of the tool set. The most we can do is document the
failings of nat as a technology, and refuse to standardize on an IPv6-IPv6
version. To some degree the NAP document is specifically trying to make the
case that mangling headers is not required once IPv4 is out of the
environment, and that all of the 'other marketed uses' of the technology are
possible using IPv6. If there are missing uses, or clearer language that
will make the case, please send text. 

Tony 

> -----Original Message-----
> From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf
> Of EricLKlein
> Sent: Saturday, November 06, 2004 12:23 AM
> To: v6ops@ops.ietf.org
> Subject: Re: NAT-PT: To deprecate or not to deprecate: the question for
> next w eek's v6ops discussion
> 
> From: "Alain Durand"
> > I think this is the crux of the issue. NAT-PT is not just NAT for v4 to
> > v6.
> > Because of its design, it adds new issue to the plate of NAT.
> >
> > IMHO, the way forward is not to pretend any translation v6->v4 is bad,
> > but to declare
> > that the specific method described in RFC2766 is problematic and thus
> > should be deprecated.
> >
> > If real need for v6 to v4 (and vice versa) emerge, it will be time to
> > look again at the issue,
> > maybe resurrect my NAT64 and NAT46 proposals or design something else.
> >
> 
> 
> I tend to disagree.
> 
> To borrow somthing Tony said in another thread:
> "The IETF needs to be about developing a
> growing and vibrant Internet, so resisting the inevitable change is
> counter
> productive. In that light, it is time to remove the special status of
> separate working groups for IPv6, and make it the default IP protocol for
> all IETF work. "
> 
> Since we as a WG have decided to depriciate NAT and not support (allow) it
> into IPv6 I think it is time that we just say that it is not supported and
> start killing it off once and for all. Otherwise we will always have to
> work
> the old NAT space and functions into the IPv6 space.
> 
> I understand the need for a transition mechanisim, but I do not feel that
> it
> is strongly stated enough the NAT is out. Not even the why you don't need
> NAT draft (draft-vandevelde-v6ops-nap-00) tries to do that.
> 
> We need to start pushing the new standards out to the market ASAP, or we
> will be trying to back fix all sorts of propritary fixes (like the DHCPv6
> issue) and will run out of addresses in the existing space ling before we
> get real acceptance of IPv6.
> 
> Eric
> 





From apache@mitre.dattaweb.com  Mon Nov  8 20:15:13 2004
Received: from mitre.dattaweb.com ([200.58.112.77])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27157
	for <v6ops-archive@lists.ietf.org>; Mon, 8 Nov 2004 20:15:12 -0500 (EST)
Received: from apache by mitre.dattaweb.com with local (Exim 4.30)
	id 1CRKFH-00048k-1T; lun, 08 nov 2004 21:52:27 -0300
Subject: Re: Letter of Introduction.
From: carol <carole_sole@circlemail.com>
X-Priority: 3 (Normal)
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: RLSP Mailer
Message-Id: <E1CRKFH-00048k-1T@mitre.dattaweb.com>
Date: lun, 08 nov 2004 21:52:27 -0300
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - mitre.dattaweb.com
X-AntiAbuse: Original Domain - lists.ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [501 503] / [502 502]
X-AntiAbuse: Sender Address Domain - mitre.dattaweb.com
Content-Transfer-Encoding: 7bit


From:Mrs Caroline Solange Haafkens of Netherlands
I am Mrs Caroline Solange Haafkens from Netherlands.
I am married to Dr.Franklyn Haafkens who worked with
ChevronTexaco in Nigeria for twenty years before he
died in the year 2000.We were married for twenty-seven
years without a child. He died during one of the riot
in the Niger delta region of Nigeria.He was held
hostage and slain to death by protesting youths of the
region.

Before his death we were both born again christians.Since his death I decided not to re-marry . When my late husband was alive he deposited the sum of (Eight Million six hundred thousand U.S.Dollars)with a bank in 
the Netherlands Presently, this money is still with the bank and the management just wrote me as the beneficiary to come forward to receive the money or rather issue a letter of authorisation to somebody to receive it on my behalf if I can not come over.

Presently, I'm with my laptop in a hospital where I have been undergoing treatment for cancer of the lungs. I have since lost my ability to talk and my doctors have told me that I have only a few months to live.

It is my last wish to see that this money is invested the proceed at the end of every year distributed among
charity organisation.I want a person that is God fearing that will use this money to fund churches,orphanages and widows propagating the word of God and to ensure that the house of God is maintained. The Bible made us to understand that Blessed is the hand that giveth.I took this decision because i know that there are alot of poor people suffering from different kind of disease and nobody to come to their aid.

With God all things are possible. As soon as I receive
your reply I shall give you the contact of the bank.
I will also issue you a letter of authority that will
prove you as the new beneficiary of this fund.You are
to help me invest this funds into real estate and
stocks.You will be entitled to 10% of every profit you
make in a year. 

Please assure me that you will act accordingly as I
stated herein.
Hoping to hearing from you soon.
waiting for your reply

Yours in Christ,
Mrs Caroline Solange Haafkens



___________________________________________________________________________
Mail enviado desde el servicio WebMail de BBY- http://www.barriosbrasilyungay.cl


From owner-v6ops@ops.ietf.org  Tue Nov  9 08:13:37 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22983
	for <v6ops-archive@lists.ietf.org>; Tue, 9 Nov 2004 08:13:36 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CRVlJ-000AW3-4p
	for v6ops-data@psg.com; Tue, 09 Nov 2004 13:10:17 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CRVl1-000ASq-VJ
	for v6ops@ops.ietf.org; Tue, 09 Nov 2004 13:10:00 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id iA9D9rF14185;
	Tue, 9 Nov 2004 15:09:53 +0200
Date: Tue, 9 Nov 2004 15:09:53 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: v6ops@ops.ietf.org
cc: Pekka Nikander <pekka.nikander@nomadiclab.com>
Subject: Ops experience of enabling MIP6 movement detection sought
Message-ID: <Pine.LNX.4.61.0411091501280.13749@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

Hi,

(co-chair hat on)

DNA working group is going to specify a BCP document how the routers 
are best configured (e.g., the intervals, consistency of prefixes, 
etc.) in a manner to support smooth IPv6 movement detection 
(typically deployed to facilitate MIPv6).

In order to get an operational take, they'd like to find person(s) who 
have operational experience with configuring the routers to 
accommodate fast movement detection.

If you've experience on this, and would like to participate 
(co-author, provide feedback, etc.), please contact me and the other 
Pekka (DNA co-chair) off-list.  Thanks.

(hat off)

-- 
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 owner-v6ops@ops.ietf.org  Tue Nov  9 13:22:20 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27224
	for <v6ops-archive@lists.ietf.org>; Tue, 9 Nov 2004 13:22:20 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CRabG-000LzE-09
	for v6ops-data@psg.com; Tue, 09 Nov 2004 18:20:14 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CRabE-000Lyc-NM
	for v6ops@ops.ietf.org; Tue, 09 Nov 2004 18:20:13 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id iA9IKB223359
	for <v6ops@ops.ietf.org>; Tue, 9 Nov 2004 20:20:11 +0200
Date: Tue, 9 Nov 2004 20:20:11 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: v6ops@ops.ietf.org
Subject: Ideas on the future of v6ops WG
Message-ID: <Pine.LNX.4.61.0411092012320.23228@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

Hi,

Various people have tried to figure out the path forward for v6ops and 
the work it has been doing. This has resulted in a number of written 
ideas.

In the interest of the open process and giving the WG to comment and 
think about the proposals at least some time in advance, they're 
available at URLs below.

Possible way to restrict the scope of v6ops to focus more on 
operational issues:

   http://netcore.fi/pekkas/ietf/61/v6ops-dow.txt

Possible start of a charter for a new, focused working group for 
setting up a v6-in-v4 tunnel, and a justification document trying to 
summarize the background for this approach:

   http://netcore.fi/pekkas/ietf/61/v6tc-charter.txt
   http://netcore.fi/pekkas/ietf/61/v6tc-justification.txt

-- 
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 owner-v6ops@ops.ietf.org  Tue Nov  9 13:42:45 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28870
	for <v6ops-archive@lists.ietf.org>; Tue, 9 Nov 2004 13:42:45 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CRawJ-000O8D-9h
	for v6ops-data@psg.com; Tue, 09 Nov 2004 18:41:59 +0000
Received: from [192.134.4.11] (helo=mx2.nic.fr)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CRawF-000O7W-9V
	for v6ops@ops.ietf.org; Tue, 09 Nov 2004 18:41:55 +0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by mx2.nic.fr (Postfix) with ESMTP
	id 34F6F26C081; Tue,  9 Nov 2004 19:41:54 +0100 (CET)
Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151])
	by mx2.nic.fr (Postfix) with ESMTP
	id 31A3026C07B; Tue,  9 Nov 2004 19:41:53 +0100 (CET)
Received: from kerkenna.nic.fr (kerkenna.nic.fr [192.134.4.98])
	by maya40.nic.fr (8.12.4/8.12.4) with ESMTP id iA9Ifr8q670610;
	Tue, 9 Nov 2004 19:41:53 +0100 (CET)
Received: from kerkenna.nic.fr (localhost [127.0.0.1])
	by kerkenna.nic.fr (8.12.10/8.12.10) with ESMTP id iA9IfqbU039642;
	Tue, 9 Nov 2004 19:41:52 +0100 (CET)
	(envelope-from souissi@kerkenna.nic.fr)
Received: (from souissi@localhost)
	by kerkenna.nic.fr (8.12.10/8.12.10/Submit) id iA9IfqKr039641;
	Tue, 9 Nov 2004 19:41:52 +0100 (CET)
	(envelope-from souissi)
Date: Tue, 9 Nov 2004 19:41:52 +0100
From: Mohsen Souissi <Mohsen.Souissi@nic.fr>
To: "Bound, Jim" <jim.bound@hp.com>
Cc: v6ops@ops.ietf.org
Subject: draft-ietf-v6ops-ent-analysis-00.txt
Message-ID: <20041109184152.GA39541@kerkenna.nic.fr>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.2.1i
X-Virus-Scanned: by amavisd-new at mx2.nic.fr
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

Hi Jim,

I can read in draft-ietf-v6ops-ent-analysis-00.txt section 7.3.2 (
"Obtaining global IPv6 address space" ) the following:

"

 Unique Local Addressing [ULAs] should not be used for enterprise
 networks.

"

I'm certainly missing something but maybe it is worth explaining, at
least in one line or with a reference to an other document, why ULAs
should not be used in enterprise networks...

Thanks for clarifying this statement.

Apart from that, in the same document:

"
7.4.1 IPv6 DNS


 The enterprise site should deploy a DNS service that is capable of
 both serving IPv6 DNS records (of the AAAA format, see RFC????) and
 of communicating over IPv6 transport.

"

==> RFC = 3596

==> Maybe reverse DNS configuration under ip6.arpa should be
recommended by the way...

Regards,

Mohsen.






From owner-v6ops@ops.ietf.org  Tue Nov  9 13:45:10 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29170
	for <v6ops-archive@lists.ietf.org>; Tue, 9 Nov 2004 13:45:10 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CRaz6-000OQY-Op
	for v6ops-data@psg.com; Tue, 09 Nov 2004 18:44:52 +0000
Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CRaz5-000OQJ-JY
	for v6ops@ops.ietf.org; Tue, 09 Nov 2004 18:44:52 +0000
Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131])
	by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id iA9IioGn025124
	for <v6ops@ops.ietf.org>; Tue, 9 Nov 2004 18:44:50 GMT
Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162])
	by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id SAA10242
	for <v6ops@ops.ietf.org>; Tue, 9 Nov 2004 18:44:49 GMT
Received: (from tjc@localhost)
	by login.ecs.soton.ac.uk (8.11.6/8.11.6) id iA9Iin403711
	for v6ops@ops.ietf.org; Tue, 9 Nov 2004 18:44:49 GMT
Date: Tue, 9 Nov 2004 18:44:49 +0000
From: Tim Chown <tjc@ecs.soton.ac.uk>
To: v6ops@ops.ietf.org
Subject: Re: draft-ietf-v6ops-ent-analysis-00.txt
Message-ID: <20041109184449.GA2791@login.ecs.soton.ac.uk>
Mail-Followup-To: v6ops@ops.ietf.org
References: <20041109184152.GA39541@kerkenna.nic.fr>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20041109184152.GA39541@kerkenna.nic.fr>
User-Agent: Mutt/1.4i
X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information
X-ECS-MailScanner: Found to be clean
X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

Hi,

This comment is being removed from the next version, fret not :)

Tim

On Tue, Nov 09, 2004 at 07:41:52PM +0100, Mohsen Souissi wrote:
> Hi Jim,
> 
> I can read in draft-ietf-v6ops-ent-analysis-00.txt section 7.3.2 (
> "Obtaining global IPv6 address space" ) the following:
> 
> "
> 
>  Unique Local Addressing [ULAs] should not be used for enterprise
>  networks.
> 
> "
> 
> I'm certainly missing something but maybe it is worth explaining, at
> least in one line or with a reference to an other document, why ULAs
> should not be used in enterprise networks...
> 
> Thanks for clarifying this statement.
> 
> Apart from that, in the same document:
> 
> "
> 7.4.1 IPv6 DNS
> 
> 
>  The enterprise site should deploy a DNS service that is capable of
>  both serving IPv6 DNS records (of the AAAA format, see RFC????) and
>  of communicating over IPv6 transport.
> 
> "
> 
> ==> RFC = 3596
> 
> ==> Maybe reverse DNS configuration under ip6.arpa should be
> recommended by the way...
> 
> Regards,
> 
> Mohsen.
> 
> 
> 

-- 
Tim

North American IPv6 Task Force Technologist Seminar
More info at http://www.ipv6seminar.com/



From owner-v6ops@ops.ietf.org  Tue Nov  9 14:21:10 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03044
	for <v6ops-archive@lists.ietf.org>; Tue, 9 Nov 2004 14:21:09 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CRbXS-0002UO-Ep
	for v6ops-data@psg.com; Tue, 09 Nov 2004 19:20:22 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CRbXR-0002U6-6M
	for v6ops@ops.ietf.org; Tue, 09 Nov 2004 19:20:21 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id iA9JKFi25345;
	Tue, 9 Nov 2004 21:20:15 +0200
Date: Tue, 9 Nov 2004 21:20:15 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: Alain Durand <Alain.Durand@sun.com>
cc: "Karen E. Nielsen (AH/LMD)" <karen.e.nielsen@ericsson.com>,
        JORDI PALET MARTINEZ <jordi.palet@consulintel.es>, v6ops@ops.ietf.org
Subject: Re: endpoint discovery from reverse DNS [Re: other comments on dr
 aft-nielsen-v6ops-3GPP-zeroconf-goals-00. txt
In-Reply-To: <418F9CB8.20801@sun.com>
Message-ID: <Pine.LNX.4.61.0411092113320.24682@netcore.fi>
References: <C26BB8276599A44B85D52F9CE41035E1050B9814@esealnt944.al.sw.ericsson.se>
 <Pine.LNX.4.61.0411081626040.13090@netcore.fi> <418F9CB8.20801@sun.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

On Mon, 8 Nov 2004, Alain Durand wrote:
>> But how many of these cases are such that a DNS search-path based approach 
>> would not be suitable (due to the requirement to have more control on which 
>> tunnel endpoints each are selected by which node, as pointed out by Alain)?
>
> Any large network that spans different locations and uses 
> potentially multiple domains. This is true for large enterprise 
> networks, but also at home if the user decided to have its own local 
> domain advertized through DHCP. For example, at home, my local DHCP 
> server is configured to send a search path as "sun.com" and 
> "mylocaldomain.example.com", but not "myISP.example.com"

I do not see this as a problem one way or the other.  If the user is 
knowledgeable to configure his/her is own DNS zone (w/ DNS server 
etc.), he's likely knowledgeable to manually configure the discovery 
process to look for protocol.myisp.com instead.

More likely than not, most if not all of those users already have v6 
acces ;-)

On the other hand, please remember that reverse DNS based 
configuration will likely need similar manual configuration as well.

> To paraphase what Rob Austien once said about automatic completion 
> using domain search list, when you do not know what the question you 
> ask is, don't be surprised if you don't find the answer.

Certainly.  The mechanism doesn't need to be perfect, especially for 
power users; it just needs to be good enough, and robust enough 
especially for those who are not sufficiently technically 
knowledgeable to do custom configuration.

> In other words, you should never believe that is advertized as your 
> domain name is relevant to figure out where you are physically on 
> the network.

Disagree.  By default it would appear to be relevant, but there are 
cases (especially when there has been manual configuration by a 
knowledgeable user) where this does not hold.  I've the assumption 
that we may not need to be all that worried about those particular 
scenarios.

But this kind of assumption needs to be spelled out.

-- 
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 owner-v6ops@ops.ietf.org  Tue Nov  9 17:44:25 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23146
	for <v6ops-archive@lists.ietf.org>; Tue, 9 Nov 2004 17:44:24 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CRehZ-000037-8p
	for v6ops-data@psg.com; Tue, 09 Nov 2004 22:43:01 +0000
Received: from [209.71.226.4] (helo=ex.hexago.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CRehY-00002u-BU
	for v6ops@ops.ietf.org; Tue, 09 Nov 2004 22:43:00 +0000
Received: from [130.129.133.2] ([130.129.133.2])
	by ex.hexago.com ( hexago/8.12.9) with ESMTP id iA9Mh8tb025357;
	Tue, 9 Nov 2004 17:43:08 -0500 (EST)
	(envelope-from Florent.Parent@hexago.com)
Date: Tue, 09 Nov 2004 17:44:44 -0500
From: Florent Parent <Florent.Parent@hexago.com>
To: Tim Chown <tjc@ecs.soton.ac.uk>, v6ops@ops.ietf.org
Subject: Re: Comments on draft-ietf-v6ops-assisted-tunneling-requirements-01
Message-ID: <7CCCA90AAB73047EBF1AFFFF@[192.168.31.2]>
In-Reply-To: <20041108183240.GR4373@login.ecs.soton.ac.uk>
References: <C5BECDD5A6B37F52EC58885A@[192.168.31.2]>
 <20041108183240.GR4373@login.ecs.soton.ac.uk>
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-3.1 required=5.0 tests=AWL,BAYES_00,SUBJ_HAS_UNIQ_ID 
	autolearn=no version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit



-- On Monday, November 08, 2004 18:32:40 +0000, Tim Chown wrote:

>> >   This discovery should be automatic when the protocol is used within
>> >   an ISP network.  There is no service discovery requirements when used
>> >   outside the provider network (roaming users, 3rd party ISP).
>> >
>> >>> But if I'm at the IETF, outside my university/ISP network, I really
>> >>> do
>> >   want to discover a tunnel end point automatically...?
>>
>> Yes, which is why its written "no service discovery requirements when
>> used  outside the provider network".
>
> I guess I read it differently... as a user I would like automatic
> discovery wherever I am; I think you are writing from the provider
> perspective?

Should we remove this paragraph and let the scope of the discovery be 
worked out in another document (tun-auto-disc)?

This would then read:


4.5  Service Discovery

   In order to facilitate deployment, the implementation should allow a
   mechanism to discover the address of the server that will provide the
   tunnel connectivity.

   Tunnel end-point discovery mechanism work
   ([I-D.palet-v6ops-tun-auto-disc] is applicable here.

Comments?

Florent



From owner-v6ops@ops.ietf.org  Tue Nov  9 18:53:43 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00155
	for <v6ops-archive@lists.ietf.org>; Tue, 9 Nov 2004 18:53:42 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CRfmM-00083V-ES
	for v6ops-data@psg.com; Tue, 09 Nov 2004 23:52:02 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CRfmL-000839-4Y
	for v6ops@ops.ietf.org; Tue, 09 Nov 2004 23:52:01 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id iA9NpxY32257
	for <v6ops@ops.ietf.org>; Wed, 10 Nov 2004 01:51:59 +0200
Date: Wed, 10 Nov 2004 01:51:59 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: v6ops@ops.ietf.org
Subject: updated v6ops agenda, presentation of way forward
Message-ID: <Pine.LNX.4.61.0411100143400.31602@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

Hi,

Slightly modified agenda for tomorrow (relating to the way forward and 
tunneling discussions) is below and posted at:

   http://netcore.fi/pekkas/ietf/61/v6ops-agenda.txt

Also, the rough slides (these will be updated a bit) are available 
beforehand at:

   http://netcore.fi/pekkas/ietf/61/way-forward.pdf

....


Wednesday 10th November -- 0900-1130
====================================

*** CRITICAL PATH ACTIVITIES ***

Introduction, agenda bashing, document status - 5 mins, Chairs/Savola
   - Scribes! (Jabber also?)

Enterprise Analysis Discussion, 15 mins, Bound
  - draft-ietf-v6ops-ent-analysis-00.txt
  - GOAL: discuss issues, so that the revision can be WGLC'ed

Discussion of the way forward - 30 mins, Chairs/WG
  - http://netcore.fi/pekkas/ietf/61/way-forward.pdf
  - http://netcore.fi/pekkas/ietf/61/v6ops-dow.txt
  - http://netcore.fi/pekkas/ietf/61/v6tc-charter.txt
  - http://netcore.fi/pekkas/ietf/61/v6tc-justification.txt
  - GOAL: discuss the scope of v6ops WG work; gain consensus on the way forward

Goals for Zero-Configuration Tunneling in 3GPP, 1 min, Nielsen
  - draft-nielsen-v6ops-3GPP-zeroconf-goals-00.txt
  - GOAL: To highlight the particularities of the 3GPP case

Generic Zero-Configuration Tunneling, 10 mins, Palet
  - http://www.v6ops.euro6ix.net/ietf/draft-suryanarayanan-v6ops-zeroconf-reqs-01.txt
  - GOAL: Discuss the issues raised, if needed.

*** OTHER IMPORTANT WORK ***

IPv6 Network Architecture Protection, 10 mins, Van de Velde
  - draft-vandevelde-v6ops-nap-00.txt
  - GOAL: introduce and start the discussion about v4 NAT alternatives in IPv6

Reason to Deprecate NAT-PT, 15 mins, Davies
  - draft-aoun-v6ops-natpt-deprecate-00.txt
  - GOAL: 5 mins presentation, 10 mins trying to decide next steps

ISP IPv6 Deployment Scenarios in Broadband Access Networks, 15 mins, Popoviciu
  - draft-asadullah-v6ops-bb-deployment-scenarios-01.txt
  - GOAL: get feedback; gauge interest and the direction

IPv6 Fix: an activity to solve barriers to IPv6 transition, 7-10 mins, Tatuya
  - A new WIDE project to fix practical IPv6 deployment issues
  - GOAL: inform the WG of activities, solicit the interested people

*** MAY BE SKIPPED IF RUNNING OUT OF TIME ***

Discussion of Teredo IETF LC comments, 5 mins, Huitema
  - draft-huitema-v6ops-teredo-02.txt
  - GOAL: describe and discuss the important IETF LC comments

IPv6 Security Overview - 5-7 mins, Davies
  - draft-savola-v6ops-security-overview-03.txt
  - GOAL: talk about differences, solicit more feedback

Things to think about when renumbering, 5-7 mins, Thompson
  - draft-chown-v6ops-renumber-thinkabout-00.txt
  - GOAL: introduce the draft, solicit feedback for next revision

IP Mobility Scenarios discussion, 5 mins, Gustafsson
  - draft-larsson-v6ops-mip-scenarios-00.txt
  - GOAL: update from the IP mobility scenarios/requirements discussion

-END-



From owner-v6ops@ops.ietf.org  Tue Nov  9 22:41:31 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17592
	for <v6ops-archive@lists.ietf.org>; Tue, 9 Nov 2004 22:41:31 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CRjKc-0009BM-PT
	for v6ops-data@psg.com; Wed, 10 Nov 2004 03:39:38 +0000
Received: from [66.218.79.80] (helo=web80510.mail.yahoo.com)
	by psg.com with smtp (Exim 4.41 (FreeBSD))
	id 1CRjKc-0009B6-0V
	for v6ops@ops.ietf.org; Wed, 10 Nov 2004 03:39:38 +0000
Message-ID: <20041110033937.26539.qmail@web80510.mail.yahoo.com>
Received: from [63.197.18.101] by web80510.mail.yahoo.com via HTTP; Tue, 09 Nov 2004 19:39:37 PST
Date: Tue, 9 Nov 2004 19:39:37 -0800 (PST)
From: Fred Templin <osprey67@yahoo.com>
Subject: Re: Flow label and Traffic Class [Re: A personal take on WG's priorities..]
To: Brian E Carpenter <brc@zurich.ibm.com>, Liu Min <liumin@ict.ac.cn>
Cc: "'Sham Chakravorty'" <schakra@mitre.org>, v6ops@ops.ietf.org
In-Reply-To: <418B54BF.1070508@zurich.ibm.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-105550129-1100057977=:26344"
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-3.8 required=5.0 tests=AWL,BAYES_00,
	FROM_ENDS_IN_NUMS,HTML_MESSAGE autolearn=no version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

--0-105550129-1100057977=:26344
Content-Type: text/plain; charset=us-ascii

Brian E Carpenter <brc@zurich.ibm.com> wrote:The Flow Label general rules are Proposed Standard (RFC 3697; also see
RFC 3595). However, we still need to describe specific use cases for the
Flow Label. That is the work that needs to be done, and anyone can
publish an I-D describing a use case, and ask for a BOF.
 
Brina - I have published such a I-D along with a companion errata:
 
  http://www.ietf.org/internet-drafts/draft-templin-ipvlx-01.txt
  http://www.ietf.org/internet-drafts/draft-templin-ipvlx-errata-04.txt
 
(see also: http://ipvlx.org for more recent updates.)
 
Would the constituency there in Washington like to have a BOF
to discuss this?
 
Fred L. Templin
osprey67@yahoo.com


--0-105550129-1100057977=:26344
Content-Type: text/html; charset=us-ascii

<DIV><STRONG><EM>Brian E Carpenter &lt;brc@zurich.ibm.com&gt;</EM></STRONG> wrote:
<BLOCKQUOTE class=replbq style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">The Flow Label general rules are Proposed Standard (RFC 3697; also see<BR>RFC 3595). However, we still need to describe specific use cases for the<BR>Flow Label. That is the work that needs to be done, and anyone can<BR>publish an I-D describing a use case, and ask for a BOF.</BLOCKQUOTE></DIV>
<DIV>&nbsp;</DIV>
<DIV>Brina - I have published such a&nbsp;I-D along with a companion errata:</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp; <A href="http://www.ietf.org/internet-drafts/draft-templin-ipvlx-01.txt">http://www.ietf.org/internet-drafts/draft-templin-ipvlx-01.txt</A></DIV>
<DIV>&nbsp; <A href="http://www.ietf.org/internet-drafts/draft-templin-ipvlx-errata-04.txt">http://www.ietf.org/internet-drafts/draft-templin-ipvlx-errata-04.txt</A></DIV>
<DIV>&nbsp;</DIV>
<DIV>(see also: <A href="http://ipvlx.org">http://ipvlx.org</A> for more recent updates.)</DIV>
<DIV>&nbsp;</DIV>
<DIV>Would the constituency there in Washington like to have a BOF</DIV>
<DIV>to discuss this?</DIV>
<DIV>&nbsp;</DIV>
<DIV>Fred L. Templin</DIV>
<DIV><A href="mailto:osprey67@yahoo.com">osprey67@yahoo.com</A><BR></DIV>
--0-105550129-1100057977=:26344--



From owner-v6ops@ops.ietf.org  Wed Nov 10 06:16:56 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23503
	for <v6ops-archive@lists.ietf.org>; Wed, 10 Nov 2004 06:16:56 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CRqQV-0005yu-CR
	for v6ops-data@psg.com; Wed, 10 Nov 2004 11:14:11 +0000
Received: from [161.114.64.105] (helo=zmamail05.zma.compaq.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CRqQU-0005yc-41
	for v6ops@ops.ietf.org; Wed, 10 Nov 2004 11:14:10 +0000
Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186])
	by zmamail05.zma.compaq.com (Postfix) with ESMTP id 559D7ADAD;
	Wed, 10 Nov 2004 06:14:09 -0500 (EST)
Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211);
	 Wed, 10 Nov 2004 06:14:09 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: updated v6ops agenda, presentation of way forward
Date: Wed, 10 Nov 2004 06:14:15 -0500
Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B07C4CC56@tayexc13.americas.cpqcorp.net>
Thread-Topic: updated v6ops agenda, presentation of way forward
Thread-Index: AcTGt5uc68jyv6gcRfixzZHUNzHDagAXmfKg
From: "Bound, Jim" <jim.bound@hp.com>
To: "Pekka Savola" <pekkas@netcore.fi>, <v6ops@ops.ietf.org>
X-OriginalArrivalTime: 10 Nov 2004 11:14:09.0155 (UTC) FILETIME=[663ABD30:01C4C716]
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

Pekka,

I want to be sure I read this correctly.  But, the way I read the URLs
below, which are all pretty good, there is no place to work on
transition mechanisms we all have been waiting to work on since NGTRANS
in the IETF. There is no protocol group to work on transition mechanisms
other than v6ops.

I for one support the charters proposed and good set of work to do on
that which is depicted. =20

But, the IETF again pokes a sharp stick in the eye of all the authors of
Teredo, DSTM, ISATAP, and Tunnel Brokers.  Not to good from my view and
cowardly indirect act, dishonroable, but as it was done in a process we
can't really blame individuals can we now.

But actually this may be a blessing finally.  It means industry and the
vendors must now look to another set of bodies to build the deployment
transition mechanisms and gather consensus from implementors these are
the methods, which users have requested from our products.  That
actually will get them done faster so this may be one of the best days
of my IPv6 life if the IETF gives up. Great.  We have waited to long.
Good news is many vendors are ready to do this out of the IETF and users
too, and several bodies are willing to take this on.  So thanks for
making a decision.

Will move forward and to the list we will have those in waiting done and
signed off by industry by Sept 2005 with the proper status as a defacto
but dejure created set of open standards for IPv6 Transition Mechanisms
and then pronounced to the market world wide to further support
decisions like 3GPP's to adopt ISATAP and we will make this body
influential for this part of the IPv6 transition. And I always do what I
say I am going to do or let you know with enough advance notice so your
not twisting in the wind waiting on what I said I was going to do. It is
a subtle attribute associated with honor.  Of course I have already
begun this process so its not like it will be from scratch as I and
others perceived this decision.  Then we will build other ones as
required.=20

P.S. Authors of DSTM, Teredo, ISATAP, and Tunnel Brokers I will be in
touch in a few weeks.

Thank You.
/jim=20

> -----Original Message-----
> From: owner-v6ops@ops.ietf.org=20
> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Pekka Savola
> Sent: Tuesday, November 09, 2004 6:52 PM
> To: v6ops@ops.ietf.org
> Subject: updated v6ops agenda, presentation of way forward
>=20
> Hi,
>=20
> Slightly modified agenda for tomorrow (relating to the way=20
> forward and tunneling discussions) is below and posted at:
>=20
>    http://netcore.fi/pekkas/ietf/61/v6ops-agenda.txt
>=20
> Also, the rough slides (these will be updated a bit) are=20
> available beforehand at:
>=20
>    http://netcore.fi/pekkas/ietf/61/way-forward.pdf
>=20
> ....
>=20
>=20
> Wednesday 10th November -- 0900-1130
> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> *** CRITICAL PATH ACTIVITIES ***
>=20
> Introduction, agenda bashing, document status - 5 mins, Chairs/Savola
>    - Scribes! (Jabber also?)
>=20
> Enterprise Analysis Discussion, 15 mins, Bound
>   - draft-ietf-v6ops-ent-analysis-00.txt
>   - GOAL: discuss issues, so that the revision can be WGLC'ed
>=20
> Discussion of the way forward - 30 mins, Chairs/WG
>   - http://netcore.fi/pekkas/ietf/61/way-forward.pdf
>   - http://netcore.fi/pekkas/ietf/61/v6ops-dow.txt
>   - http://netcore.fi/pekkas/ietf/61/v6tc-charter.txt
>   - http://netcore.fi/pekkas/ietf/61/v6tc-justification.txt
>   - GOAL: discuss the scope of v6ops WG work; gain consensus=20
> on the way forward
>=20
> Goals for Zero-Configuration Tunneling in 3GPP, 1 min, Nielsen
>   - draft-nielsen-v6ops-3GPP-zeroconf-goals-00.txt
>   - GOAL: To highlight the particularities of the 3GPP case
>=20
> Generic Zero-Configuration Tunneling, 10 mins, Palet
>   -=20
> http://www.v6ops.euro6ix.net/ietf/draft-suryanarayanan-v6ops-z
> eroconf-reqs-01.txt
>   - GOAL: Discuss the issues raised, if needed.
>=20
> *** OTHER IMPORTANT WORK ***
>=20
> IPv6 Network Architecture Protection, 10 mins, Van de Velde
>   - draft-vandevelde-v6ops-nap-00.txt
>   - GOAL: introduce and start the discussion about v4 NAT=20
> alternatives in IPv6
>=20
> Reason to Deprecate NAT-PT, 15 mins, Davies
>   - draft-aoun-v6ops-natpt-deprecate-00.txt
>   - GOAL: 5 mins presentation, 10 mins trying to decide next steps
>=20
> ISP IPv6 Deployment Scenarios in Broadband Access Networks,=20
> 15 mins, Popoviciu
>   - draft-asadullah-v6ops-bb-deployment-scenarios-01.txt
>   - GOAL: get feedback; gauge interest and the direction
>=20
> IPv6 Fix: an activity to solve barriers to IPv6 transition,=20
> 7-10 mins, Tatuya
>   - A new WIDE project to fix practical IPv6 deployment issues
>   - GOAL: inform the WG of activities, solicit the interested people
>=20
> *** MAY BE SKIPPED IF RUNNING OUT OF TIME ***
>=20
> Discussion of Teredo IETF LC comments, 5 mins, Huitema
>   - draft-huitema-v6ops-teredo-02.txt
>   - GOAL: describe and discuss the important IETF LC comments
>=20
> IPv6 Security Overview - 5-7 mins, Davies
>   - draft-savola-v6ops-security-overview-03.txt
>   - GOAL: talk about differences, solicit more feedback
>=20
> Things to think about when renumbering, 5-7 mins, Thompson
>   - draft-chown-v6ops-renumber-thinkabout-00.txt
>   - GOAL: introduce the draft, solicit feedback for next revision
>=20
> IP Mobility Scenarios discussion, 5 mins, Gustafsson
>   - draft-larsson-v6ops-mip-scenarios-00.txt
>   - GOAL: update from the IP mobility scenarios/requirements=20
> discussion
>=20
> -END-
>=20
>=20



From owner-v6ops@ops.ietf.org  Wed Nov 10 06:51:24 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26022
	for <v6ops-archive@lists.ietf.org>; Wed, 10 Nov 2004 06:51:24 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CRqzw-000A5A-1q
	for v6ops-data@psg.com; Wed, 10 Nov 2004 11:50:48 +0000
Received: from [66.218.79.76] (helo=web80506.mail.yahoo.com)
 	by psg.com with smtp (Exim 4.41 (FreeBSD))
 	id 1CRjQ1-0009qK-8X
 	for v6ops@ops.ietf.org; Wed, 10 Nov 2004 03:45:13 +0000
Message-ID: <20041110034512.522.qmail@web80506.mail.yahoo.com>
Received: from [63.197.18.101] by web80506.mail.yahoo.com via HTTP; Tue, 09 Nov 2004 19:45:12 PST
Date: Tue, 9 Nov 2004 19:45:12 -0800 (PST)
From: Fred Templin <cktflt@pacbell.net>
Subject: Re: Flow label and Traffic Class [Re: A personal take on WG's priorities..]
To: Fred Templin <osprey67@yahoo.com>, Brian E Carpenter <brc@zurich.ibm.com>,
        Liu Min <liumin@ict.ac.cn>
Cc: "'Sham Chakravorty'" <schakra@mitre.org>, v6ops@ops.ietf.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-624434702-1100058312=:96791"
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,HTML_MESSAGE
 	autolearn=ham version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

--0-624434702-1100058312=:96791
Content-Type: text/plain; charset=us-ascii

Fred Templin <osprey67@yahoo.com> wrote:Brina - I have published such a I-D along with a companion errata:

^^^^^
Umm - sorry about the fat-fingers, Brian.

Fred
osprey67@yahoo.com




--0-624434702-1100058312=:96791
Content-Type: text/html; charset=us-ascii

<DIV><STRONG><EM>Fred Templin &lt;osprey67@yahoo.com&gt;</EM></STRONG> wrote:
<BLOCKQUOTE class=replbq style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">
<DIV>Brina - I have published such a&nbsp;I-D along with a companion errata:</DIV></BLOCKQUOTE></DIV>
<DIV>^^^^^</DIV>
<DIV>Umm - sorry about the fat-fingers, Brian.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Fred</DIV>
<DIV><A href="mailto:osprey67@yahoo.com">osprey67@yahoo.com</A></DIV>
<DIV><BR><BR>&nbsp;</DIV>
--0-624434702-1100058312=:96791--



From owner-v6ops@ops.ietf.org  Wed Nov 10 07:07:32 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27103
	for <v6ops-archive@lists.ietf.org>; Wed, 10 Nov 2004 07:07:31 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CRrFh-000CQX-2V
	for v6ops-data@psg.com; Wed, 10 Nov 2004 12:07:05 +0000
Received: from [203.254.224.24] (helo=mailout1.samsung.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CRrFg-000CQC-2n
	for v6ops@ops.ietf.org; Wed, 10 Nov 2004 12:07:04 +0000
Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com
 (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004))
 id <0I6Y00G01PNQ6K@mailout1.samsung.com> for v6ops@ops.ietf.org; Wed,
 10 Nov 2004 21:07:02 +0900 (KST)
Received: from ep_ms13_bk (mailout1.samsung.com [203.254.224.24])
 by mailout1.samsung.com
 (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004))
 with ESMTP id <0I6Y00LLMPNPQQ@mailout1.samsung.com> for v6ops@ops.ietf.org;
 Wed, 10 Nov 2004 21:07:01 +0900 (KST)
Received: from ep_spt03 (ms13.samsung.com [203.254.225.109])
 by ms13.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004))
 with ESMTP id <0I6Y008BGPNPXF@ms13.samsung.com> for v6ops@ops.ietf.org; Wed,
 10 Nov 2004 21:07:01 +0900 (KST)
Content-return: prohibited
Date: Wed, 10 Nov 2004 12:07:06 +0000 (GMT)
From: Syam Madanpalli <syam@samsung.com>
Subject: Re: updated v6ops agenda, presentation of way forward
X-Sender: =?windows-1252?B?U2Ftc3VuZyBFbGVjdHJvbmljcz9TSVNPP01hbmFnZXI=?=
To: Pekka Savola <pekkas@netcore.fi>
Cc: "v6ops@ops.ietf.org " <v6ops@ops.ietf.org>
Reply-to: syam@samsung.com
Message-id: <0I6Y008BHPNPXF@ms13.samsung.com>
MIME-version: 1.0
Content-type: text/html; charset=windows-1252
Content-transfer-encoding: 7BIT
X-Priority: 3
Msgkey: 20041110120658653@syam
X-MTR: 20041110120658653@syam
X-EPLocale: en_US.windows-1252
X-EPWebmail-Msg-Type: personal
X-EPWebmail-Reply-Demand: 0
X-Generator: NamoMIME 1.1.0.17
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-3.3 required=5.0 tests=BAYES_00,HTML_MESSAGE,
	MIME_HTML_ONLY,PRIORITY_NO_NAME autolearn=no version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7BIT

<HTML><HEAD>
<META http-equiv=Content-Type content='text/html; charset=windows-1252'>
<title>Samsung Enterprise Portal mySingle</title>
<style> P, td, li {font-family:Arial, arial; font-size:9pt; margin-top:5px;margin-bottom:5px;}</style>
</HEAD><BODY><p>Hi Pekka,
<p><br>This move looks good. And I have a question on the proposed&nbsp;new 
Tunneling WG.</p>
<p>We are going to develop an entirely new protocol based on the ZCT Requirements?</p>
<p>or WG wants to start with some existing methods and form a design team to 
develop</p>
<p>an unified method?</p>
<p>&nbsp;</p>
<p>Thank you,</p>
<p>Syam</p>
<p><br><br><br><br>------- <b>Original Message</b> -------<br><b>Sender</b> : Pekka Savola&lt;pekkas@netcore.fi&gt;<br><b>Date</b>   : Nov 09, 2004 18:51<br><b>Title</b>  : updated v6ops agenda, presentation of way forward<br>Hi,
<br>
<br>Slightly&nbsp;modified&nbsp;agenda&nbsp;for&nbsp;tomorrow&nbsp;(relating&nbsp;to&nbsp;the&nbsp;way&nbsp;forward&nbsp;and&nbsp;
<br>tunneling&nbsp;discussions)&nbsp;is&nbsp;below&nbsp;and&nbsp;posted&nbsp;at:
<br>
<br>&nbsp;&nbsp;&nbsp;http://netcore.fi/pekkas/ietf/61/v6ops-agenda.txt
<br>
<br>Also,&nbsp;the&nbsp;rough&nbsp;slides&nbsp;(these&nbsp;will&nbsp;be&nbsp;updated&nbsp;a&nbsp;bit)&nbsp;are&nbsp;available&nbsp;
<br>beforehand&nbsp;at:
<br>
<br>&nbsp;&nbsp;&nbsp;http://netcore.fi/pekkas/ietf/61/way-forward.pdf
<br>
<br>....
<br>
<br>
<br></p>
</BODY></HTML>



From owner-v6ops@ops.ietf.org  Wed Nov 10 07:10:49 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27438
	for <v6ops-archive@lists.ietf.org>; Wed, 10 Nov 2004 07:10:49 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CRrJ2-000Czx-TB
	for v6ops-data@psg.com; Wed, 10 Nov 2004 12:10:32 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CRrJ1-000Cyx-KT
	for v6ops@ops.ietf.org; Wed, 10 Nov 2004 12:10:32 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id iAACAQR16182;
	Wed, 10 Nov 2004 14:10:27 +0200
Date: Wed, 10 Nov 2004 14:10:26 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: Syam Madanpalli <syam@samsung.com>
cc: "v6ops@ops.ietf.org " <v6ops@ops.ietf.org>
Subject: Re: updated v6ops agenda, presentation of way forward
In-Reply-To: <0I6Y008BHPNPXF@ms13.samsung.com>
Message-ID: <Pine.LNX.4.61.0411101408180.15510@netcore.fi>
References: <0I6Y008BHPNPXF@ms13.samsung.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

On Wed, 10 Nov 2004, Syam Madanpalli wrote:
> We are going to develop an entirely new protocol based on the ZCT 
> Requirements?

If you read it carefully, the proposal goes a bit further than the 
original ZCT proposals, because the authentication scenario is also 
included. (Feedback is welcome on this.)

> or WG wants to start with some existing methods and form a design team to
> develop an unified method?

That would remain to be seen.  Multiple proposals are probably also 
OK.  I would expect at least some small team is going to get together 
and try to propose at least one solution.

-- 
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 owner-v6ops@ops.ietf.org  Wed Nov 10 07:35:19 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00230
	for <v6ops-archive@lists.ietf.org>; Wed, 10 Nov 2004 07:35:18 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CRrfU-000FYB-SI
	for v6ops-data@psg.com; Wed, 10 Nov 2004 12:33:44 +0000
Received: from [213.197.29.32] (helo=noc.sixxs.net)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CRrfT-000FXt-QE
	for v6ops@ops.ietf.org; Wed, 10 Nov 2004 12:33:44 +0000
Received: from localhost (localhost [127.0.0.1])
	by noc.sixxs.net (Postfix) with ESMTP id 5B54C2400B;
	Wed, 10 Nov 2004 13:33:42 +0100 (CET)
Received: from noc.sixxs.net ([127.0.0.1])
	by localhost (noc [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
	id 08715-09; Wed, 10 Nov 2004 13:33:36 +0100 (CET)
Received: from firenze.zurich.ibm.com (pat.zurich.ibm.com [195.176.20.45])
	(using SSLv3 with cipher RC4-MD5 (128/128 bits))
	(No client certificate requested)
	by noc.sixxs.net (Postfix) with ESMTP id 441D724010;
	Wed, 10 Nov 2004 13:33:31 +0100 (CET)
Subject: Re: updated v6ops agenda, presentation of way forward
From: Jeroen Massar <jeroen@unfix.org>
To: Pekka Savola <pekkas@netcore.fi>, v6ops@ops.ietf.org
In-Reply-To: <0I6Y008BHPNPXF@ms13.samsung.com>
References: <0I6Y008BHPNPXF@ms13.samsung.com>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-FLh0HzWs1EqR80uIdB8Q"
Organization: Unfix
Date: Wed, 10 Nov 2004 13:33:29 +0100
Message-Id: <1100090009.30064.21.camel@firenze.zurich.ibm.com>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.2 (2.0.2-4) 
X-Virus-Scanned: noc.sixxs.net - http://www.sixxs.net
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk


--=-FLh0HzWs1EqR80uIdB8Q
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Pekka Savola wrote:

<SNIP>
> Also, the rough slides (these will be updated a bit) are available =20
> beforehand at:=20
>=20
>    http://netcore.fi/pekkas/ietf/61/way-forward.pdf=20

8<-----------------
Propose a new WG to write a new IPv6 over IPv4 tunneling protocol
1. Based on the tunneling requirements write one new protocol
2. Work on two components of the solution:
   a) method to discover the tunnel end-point
   b) specification of the tunnel set-up protocol
----------------->8

There are three components to "Tunneling", the third is the actual
protocol, but you mention that in the first part, probably a rephrase
would be better.

Is this only about Tunneling IPv6 over something, or is it a generic
tunneling solution, the latter is called pptp and all the other variants
that already have existed for quite some time, next to that there are a
number of drafts which have been submitted for quite some time already
surrounding this subject and specifically for doing IPv6 over NAT-
crippled IPv4 hosts. I don't recall seeing a draft about Hexago's
v6udpv4 protocol though, not that it is complex but still.

Greets,
 Jeroen


--=-FLh0HzWs1EqR80uIdB8Q
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Jeroen Massar / http://unfix.org/~jeroen/

iD8DBQBBkgqZKaooUjM+fCMRAs5gAKCWtFaWqmAKpa36XD2V/Mshz3SOLwCgoAZl
fDUdTG9PJ6aN/eHn6p1WOxQ=
=Nd0N
-----END PGP SIGNATURE-----

--=-FLh0HzWs1EqR80uIdB8Q--




From owner-v6ops@ops.ietf.org  Wed Nov 10 07:44:25 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01533
	for <v6ops-archive@lists.ietf.org>; Wed, 10 Nov 2004 07:44:24 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CRrpT-000Gk1-5b
	for v6ops-data@psg.com; Wed, 10 Nov 2004 12:44:03 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CRrpJ-000GhK-JP
	for v6ops@ops.ietf.org; Wed, 10 Nov 2004 12:43:54 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id iAACh8Y16977;
	Wed, 10 Nov 2004 14:43:08 +0200
Date: Wed, 10 Nov 2004 14:43:08 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: "Bound, Jim" <jim.bound@hp.com>
cc: v6ops@ops.ietf.org
Subject: RE: updated v6ops agenda, presentation of way forward
In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B07C4CC56@tayexc13.americas.cpqcorp.net>
Message-ID: <Pine.LNX.4.61.0411101433240.16711@netcore.fi>
References: <9C422444DE99BC46B3AD3C6EAFC9711B07C4CC56@tayexc13.americas.cpqcorp.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

Jim,

Just clarifying a few points below..

On Wed, 10 Nov 2004, Bound, Jim wrote:
> I want to be sure I read this correctly.  But, the way I read the 
> URLs below, which are all pretty good, there is no place to work on 
> transition mechanisms we all have been waiting to work on since 
> NGTRANS in the IETF. There is no protocol group to work on 
> transition mechanisms other than v6ops.

It was thought to be a good idea not to create a generic protocol 
working group, but rather use very focused ones or individual 
submission as appropriate.  This can of course be discussed during the 
sessions.

> But, the IETF again pokes a sharp stick in the eye of all the authors of
> Teredo, DSTM, ISATAP, and Tunnel Brokers.  Not to good from my view and
> cowardly indirect act, dishonroable, but as it was done in a process we
> can't really blame individuals can we now.

In case you haven't followed closely what has been happening, Teredo 
has already passed IETF Last Call for PS through an individual 
submission, and the WG being proposed seems to fulfill the problem 
space solved by tunnel brokers.

When the proposal was formulating, there was actually initially some 
discussion whether v4-over-v6 should be somehow included there. 
However, it was felt that that would de-focus this work, because we 
don't really know the scenarios and the requirements yet.  When those 
are clearer, it could be then decided what would be the most 
appropriate way to go forward with that work.

But again, this is something that can be discussed.

-- 
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 owner-v6ops@ops.ietf.org  Wed Nov 10 07:53:46 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02396
	for <v6ops-archive@lists.ietf.org>; Wed, 10 Nov 2004 07:53:46 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CRryR-000I9L-BM
	for v6ops-data@psg.com; Wed, 10 Nov 2004 12:53:19 +0000
Received: from [161.114.64.105] (helo=zmamail05.zma.compaq.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CRryQ-000I92-D5
	for v6ops@ops.ietf.org; Wed, 10 Nov 2004 12:53:18 +0000
Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186])
	by zmamail05.zma.compaq.com (Postfix) with ESMTP id AE860AE85;
	Wed, 10 Nov 2004 07:53:17 -0500 (EST)
Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211);
	 Wed, 10 Nov 2004 07:53:17 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: updated v6ops agenda, presentation of way forward
Date: Wed, 10 Nov 2004 07:53:23 -0500
Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B07C4CC76@tayexc13.americas.cpqcorp.net>
Thread-Topic: updated v6ops agenda, presentation of way forward
Thread-Index: AcTHHl27VtDTra+kTDuFoLaQL/DyVQABbkTA
From: "Bound, Jim" <jim.bound@hp.com>
To: "Pekka Savola" <pekkas@netcore.fi>, "Syam Madanpalli" <syam@samsung.com>
Cc: <v6ops@ops.ietf.org>
X-OriginalArrivalTime: 10 Nov 2004 12:53:17.0454 (UTC) FILETIME=[3FB122E0:01C4C724]
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

Pekka,

For clarity.  You say multiple proposals are "probably" ok?  That sounds
dictatorial and I don't think you mean't it that way did you?  The
objective of the IETF is to bring good ideas to our body?

Please clarify for the community your statement?

Thanks
/jim=20

> -----Original Message-----
> From: owner-v6ops@ops.ietf.org=20
> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Pekka Savola
> Sent: Wednesday, November 10, 2004 7:10 AM
> To: Syam Madanpalli
> Cc: v6ops@ops.ietf.org=20
> Subject: Re: updated v6ops agenda, presentation of way forward
>=20
> On Wed, 10 Nov 2004, Syam Madanpalli wrote:
> > We are going to develop an entirely new protocol based on the ZCT=20
> > Requirements?
>=20
> If you read it carefully, the proposal goes a bit further=20
> than the original ZCT proposals, because the authentication=20
> scenario is also included. (Feedback is welcome on this.)
>=20
> > or WG wants to start with some existing methods and form a=20
> design team=20
> > to develop an unified method?
>=20
> That would remain to be seen.  Multiple proposals are=20
> probably also OK.  I would expect at least some small team is=20
> going to get together and try to propose at least one solution.
>=20
> --=20
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>=20
>=20



From owner-v6ops@ops.ietf.org  Wed Nov 10 07:56:11 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02729
	for <v6ops-archive@lists.ietf.org>; Wed, 10 Nov 2004 07:56:11 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CRs11-000IcB-5W
	for v6ops-data@psg.com; Wed, 10 Nov 2004 12:55:59 +0000
Received: from [161.114.64.104] (helo=zmamail04.zma.compaq.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CRs10-000Ibw-66
	for v6ops@ops.ietf.org; Wed, 10 Nov 2004 12:55:58 +0000
Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127])
	by zmamail04.zma.compaq.com (Postfix) with ESMTP id D501052F9;
	Wed, 10 Nov 2004 07:55:57 -0500 (EST)
Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211);
	 Wed, 10 Nov 2004 07:55:57 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: updated v6ops agenda, presentation of way forward
Date: Wed, 10 Nov 2004 07:56:03 -0500
Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B07C4CC7A@tayexc13.americas.cpqcorp.net>
Thread-Topic: updated v6ops agenda, presentation of way forward
Thread-Index: AcTHIvPLF7bkGZTqSpGoij5870dnJgAAX/fQ
From: "Bound, Jim" <jim.bound@hp.com>
To: "Pekka Savola" <pekkas@netcore.fi>
Cc: <v6ops@ops.ietf.org>
X-OriginalArrivalTime: 10 Nov 2004 12:55:57.0752 (UTC) FILETIME=[9F3CAB80:01C4C724]
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

Pekka,

Thanks for the response.  No I had not heard that about Teredo status
only that it had went to the IESG so that is good I agree.

I will think about it I am thinking now it might be faster to do this
out of the IETF if a process can be created and support an open
standards view in another body.

Thanks
/jim=20

> -----Original Message-----
> From: Pekka Savola [mailto:pekkas@netcore.fi]=20
> Sent: Wednesday, November 10, 2004 7:43 AM
> To: Bound, Jim
> Cc: v6ops@ops.ietf.org
> Subject: RE: updated v6ops agenda, presentation of way forward
>=20
> Jim,
>=20
> Just clarifying a few points below..
>=20
> On Wed, 10 Nov 2004, Bound, Jim wrote:
> > I want to be sure I read this correctly.  But, the way I=20
> read the URLs=20
> > below, which are all pretty good, there is no place to work on=20
> > transition mechanisms we all have been waiting to work on since=20
> > NGTRANS in the IETF. There is no protocol group to work on=20
> transition=20
> > mechanisms other than v6ops.
>=20
> It was thought to be a good idea not to create a generic=20
> protocol working group, but rather use very focused ones or=20
> individual submission as appropriate.  This can of course be=20
> discussed during the sessions.
>=20
> > But, the IETF again pokes a sharp stick in the eye of all=20
> the authors=20
> > of Teredo, DSTM, ISATAP, and Tunnel Brokers.  Not to good=20
> from my view=20
> > and cowardly indirect act, dishonroable, but as it was done in a=20
> > process we can't really blame individuals can we now.
>=20
> In case you haven't followed closely what has been happening,=20
> Teredo has already passed IETF Last Call for PS through an=20
> individual submission, and the WG being proposed seems to=20
> fulfill the problem space solved by tunnel brokers.
>=20
> When the proposal was formulating, there was actually=20
> initially some discussion whether v4-over-v6 should be=20
> somehow included there.=20
> However, it was felt that that would de-focus this work,=20
> because we don't really know the scenarios and the=20
> requirements yet.  When those are clearer, it could be then=20
> decided what would be the most appropriate way to go forward=20
> with that work.
>=20
> But again, this is something that can be discussed.
>=20
> --=20
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>=20



From owner-v6ops@ops.ietf.org  Wed Nov 10 07:58:19 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02867
	for <v6ops-archive@lists.ietf.org>; Wed, 10 Nov 2004 07:58:19 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CRs38-000IyH-D2
	for v6ops-data@psg.com; Wed, 10 Nov 2004 12:58:10 +0000
Received: from [161.114.64.103] (helo=zmamail03.zma.compaq.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CRs37-000Ixi-Aa
	for v6ops@ops.ietf.org; Wed, 10 Nov 2004 12:58:09 +0000
Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127])
	by zmamail03.zma.compaq.com (Postfix) with ESMTP id C264D53;
	Wed, 10 Nov 2004 07:58:08 -0500 (EST)
Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211);
	 Wed, 10 Nov 2004 07:58:08 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: updated v6ops agenda, presentation of way forward
Date: Wed, 10 Nov 2004 07:58:14 -0500
Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B07C4CC7C@tayexc13.americas.cpqcorp.net>
Thread-Topic: updated v6ops agenda, presentation of way forward
Thread-Index: AcTHHl27VtDTra+kTDuFoLaQL/DyVQABbkTAAAAmIUA=
From: "Bound, Jim" <jim.bound@hp.com>
To: "Bound, Jim" <jim.bound@hp.com>, "Pekka Savola" <pekkas@netcore.fi>,
        "Syam Madanpalli" <syam@samsung.com>
Cc: <v6ops@ops.ietf.org>
X-OriginalArrivalTime: 10 Nov 2004 12:58:08.0674 (UTC) FILETIME=[ED45C820:01C4C724]
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

Pekka,

I think it is fine to say also that we have tunneling proposals which
exist and what we want to do is work the security which you did follow
up on.  If we believe there are no other good ideas out there right now
because we must ship something which I think is the first priority.

Thanks
/jim=20

> -----Original Message-----
> From: owner-v6ops@ops.ietf.org=20
> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Bound, Jim
> Sent: Wednesday, November 10, 2004 7:53 AM
> To: Pekka Savola; Syam Madanpalli
> Cc: v6ops@ops.ietf.org
> Subject: RE: updated v6ops agenda, presentation of way forward
>=20
> Pekka,
>=20
> For clarity.  You say multiple proposals are "probably" ok? =20
> That sounds dictatorial and I don't think you mean't it that=20
> way did you?  The objective of the IETF is to bring good=20
> ideas to our body?
>=20
> Please clarify for the community your statement?
>=20
> Thanks
> /jim=20
>=20
> > -----Original Message-----
> > From: owner-v6ops@ops.ietf.org
> > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Pekka Savola
> > Sent: Wednesday, November 10, 2004 7:10 AM
> > To: Syam Madanpalli
> > Cc: v6ops@ops.ietf.org
> > Subject: Re: updated v6ops agenda, presentation of way forward
> >=20
> > On Wed, 10 Nov 2004, Syam Madanpalli wrote:
> > > We are going to develop an entirely new protocol based on the ZCT=20
> > > Requirements?
> >=20
> > If you read it carefully, the proposal goes a bit further than the=20
> > original ZCT proposals, because the authentication scenario is also=20
> > included. (Feedback is welcome on this.)
> >=20
> > > or WG wants to start with some existing methods and form a
> > design team
> > > to develop an unified method?
> >=20
> > That would remain to be seen.  Multiple proposals are probably also=20
> > OK.  I would expect at least some small team is going to=20
> get together=20
> > and try to propose at least one solution.
> >=20
> > --=20
> > Pekka Savola                 "You each name yourselves king, yet the
> > Netcore Oy                    kingdom bleeds."
> > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> >=20
> >=20
>=20
>=20



From owner-v6ops@ops.ietf.org  Wed Nov 10 08:05:58 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03742
	for <v6ops-archive@lists.ietf.org>; Wed, 10 Nov 2004 08:05:58 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CRsAB-000KGK-8J
	for v6ops-data@psg.com; Wed, 10 Nov 2004 13:05:27 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CRsA9-000KFb-Mv
	for v6ops@ops.ietf.org; Wed, 10 Nov 2004 13:05:26 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id iAAD5Gd17720;
	Wed, 10 Nov 2004 15:05:19 +0200
Date: Wed, 10 Nov 2004 15:05:16 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: Jeroen Massar <jeroen@unfix.org>
cc: v6ops@ops.ietf.org
Subject: Re: updated v6ops agenda, presentation of way forward
In-Reply-To: <1100090009.30064.21.camel@firenze.zurich.ibm.com>
Message-ID: <Pine.LNX.4.61.0411101452180.17270@netcore.fi>
References: <0I6Y008BHPNPXF@ms13.samsung.com> <1100090009.30064.21.camel@firenze.zurich.ibm.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

Hi,

First, a clarification to Jim:

> For clarity.  You say multiple proposals are "probably" ok?  That 
> sounds dictatorial and I don't think you mean't it that way did you? 
> The objective of the IETF is to bring good ideas to our body?

Sorry for the word: too few words.  What I meant to say is that 
multiple proposals are of course OK, but because then the WG would 
have to apply a selection process, it would be desirable (for speed, 
etc.) not to have *too* many proposals: i.e., having multiple 
proposals doesn't have inherent value in itself :).  Selection among 
many would likely be a time-consuming process, so the attempt would be 
to try to propose one that most people would be comfortable with.

On Wed, 10 Nov 2004, Jeroen Massar wrote:
> 8<-----------------
> Propose a new WG to write a new IPv6 over IPv4 tunneling protocol
> 1. Based on the tunneling requirements write one new protocol
> 2. Work on two components of the solution:
>   a) method to discover the tunnel end-point
>   b) specification of the tunnel set-up protocol
> ----------------->8
>
> There are three components to "Tunneling", the third is the actual
> protocol, but you mention that in the first part, probably a rephrase
> would be better.

Agreed.  We'll try to do that before the final presentation.

> Is this only about Tunneling IPv6 over something, or is it a generic
> tunneling solution,

Only about v6 over v4[-udp].  It was felt that the focus must be on 
what we know reasonably well.

That is not to say that the solution could not be done in such a way 
that extending it would be simple later on, but that is not a goal of 
the work.

> next to that there are a number of drafts which have been submitted 
> for quite some time already surrounding this subject and 
> specifically for doing IPv6 over NAT- crippled IPv4 hosts. I don't 
> recall seeing a draft about Hexago's v6udpv4 protocol though, not 
> that it is complex but still.

Yes, there have definitely been drafts :).  It seemed that these have 
some short-comings though, so that trying to merge the best parts of 
each to one proposal might make sense.

-- 
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 owner-v6ops@ops.ietf.org  Wed Nov 10 08:11:24 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04652
	for <v6ops-archive@lists.ietf.org>; Wed, 10 Nov 2004 08:11:24 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CRsFJ-000L5j-G9
	for v6ops-data@psg.com; Wed, 10 Nov 2004 13:10:45 +0000
Received: from [161.114.64.105] (helo=zmamail05.zma.compaq.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CRsFI-000L5V-BC
	for v6ops@ops.ietf.org; Wed, 10 Nov 2004 13:10:44 +0000
Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186])
	by zmamail05.zma.compaq.com (Postfix) with ESMTP id 006A592D1;
	Wed, 10 Nov 2004 08:10:43 -0500 (EST)
Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211);
	 Wed, 10 Nov 2004 08:10:43 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: updated v6ops agenda, presentation of way forward
Date: Wed, 10 Nov 2004 08:10:49 -0500
Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B07C4CC87@tayexc13.americas.cpqcorp.net>
Thread-Topic: updated v6ops agenda, presentation of way forward
Thread-Index: AcTHJhpN8MBNPDJ9TSaCncMBwMRaWQAADb6g
From: "Bound, Jim" <jim.bound@hp.com>
To: "Pekka Savola" <pekkas@netcore.fi>, "Jeroen Massar" <jeroen@unfix.org>
Cc: <v6ops@ops.ietf.org>
X-OriginalArrivalTime: 10 Nov 2004 13:10:43.0800 (UTC) FILETIME=[AF5CDD80:01C4C726]
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

Thanks for my answer I agree and makes sense to get this done.  FYI
early adopters are setting up tunnels now and using multiple approaches
to discover TEPS.  The ones I am seeing dominant right now are private
company/provider tunnel brokers with set up and hand configured TEPs,
mannual tunnel configured TEPs at edges, and to lesser degree DHCPv6
with custom extensions.  So a TEP discovery solution is required for
sure.

/jim=20

> -----Original Message-----
> From: owner-v6ops@ops.ietf.org=20
> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Pekka Savola
> Sent: Wednesday, November 10, 2004 8:05 AM
> To: Jeroen Massar
> Cc: v6ops@ops.ietf.org
> Subject: Re: updated v6ops agenda, presentation of way forward
>=20
> Hi,
>=20
> First, a clarification to Jim:
>=20
> > For clarity.  You say multiple proposals are "probably" ok?  That=20
> > sounds dictatorial and I don't think you mean't it that way did you?
> > The objective of the IETF is to bring good ideas to our body?
>=20
> Sorry for the word: too few words.  What I meant to say is=20
> that multiple proposals are of course OK, but because then=20
> the WG would have to apply a selection process, it would be=20
> desirable (for speed,
> etc.) not to have *too* many proposals: i.e., having multiple=20
> proposals doesn't have inherent value in itself :). =20
> Selection among many would likely be a time-consuming=20
> process, so the attempt would be to try to propose one that=20
> most people would be comfortable with.
>=20
> On Wed, 10 Nov 2004, Jeroen Massar wrote:
> > 8<-----------------
> > Propose a new WG to write a new IPv6 over IPv4 tunneling=20
> protocol 1.=20
> > Based on the tunneling requirements write one new protocol=20
> 2. Work on=20
> > two components of the solution:
> >   a) method to discover the tunnel end-point
> >   b) specification of the tunnel set-up protocol
> > ----------------->8
> >
> > There are three components to "Tunneling", the third is the actual=20
> > protocol, but you mention that in the first part, probably=20
> a rephrase=20
> > would be better.
>=20
> Agreed.  We'll try to do that before the final presentation.
>=20
> > Is this only about Tunneling IPv6 over something, or is it=20
> a generic=20
> > tunneling solution,
>=20
> Only about v6 over v4[-udp].  It was felt that the focus must=20
> be on what we know reasonably well.
>=20
> That is not to say that the solution could not be done in=20
> such a way that extending it would be simple later on, but=20
> that is not a goal of the work.
>=20
> > next to that there are a number of drafts which have been submitted=20
> > for quite some time already surrounding this subject and=20
> specifically=20
> > for doing IPv6 over NAT- crippled IPv4 hosts. I don't=20
> recall seeing a=20
> > draft about Hexago's v6udpv4 protocol though, not that it=20
> is complex=20
> > but still.
>=20
> Yes, there have definitely been drafts :).  It seemed that=20
> these have some short-comings though, so that trying to merge=20
> the best parts of each to one proposal might make sense.
>=20
> --=20
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>=20
>=20



From owner-v6ops@ops.ietf.org  Wed Nov 10 08:37:13 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06934
	for <v6ops-archive@lists.ietf.org>; Wed, 10 Nov 2004 08:37:13 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CRsc8-000Of5-3L
	for v6ops-data@psg.com; Wed, 10 Nov 2004 13:34:20 +0000
Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CRsc7-000Oee-16
	for v6ops@ops.ietf.org; Wed, 10 Nov 2004 13:34:19 +0000
Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131])
	by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id iAADYHGn020803
	for <v6ops@ops.ietf.org>; Wed, 10 Nov 2004 13:34:17 GMT
Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162])
	by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id NAA18870
	for <v6ops@ops.ietf.org>; Wed, 10 Nov 2004 13:34:16 GMT
Received: (from tjc@localhost)
	by login.ecs.soton.ac.uk (8.11.6/8.11.6) id iAADYGr22437
	for v6ops@ops.ietf.org; Wed, 10 Nov 2004 13:34:16 GMT
Date: Wed, 10 Nov 2004 13:34:16 +0000
From: Tim Chown <tjc@ecs.soton.ac.uk>
To: v6ops@ops.ietf.org
Subject: Re: updated v6ops agenda, presentation of way forward
Message-ID: <20041110133416.GJ21680@login.ecs.soton.ac.uk>
Mail-Followup-To: v6ops@ops.ietf.org
References: <0I6Y008BHPNPXF@ms13.samsung.com> <1100090009.30064.21.camel@firenze.zurich.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1100090009.30064.21.camel@firenze.zurich.ibm.com>
User-Agent: Mutt/1.4i
X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information
X-ECS-MailScanner: Found to be clean
X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

On Wed, Nov 10, 2004 at 01:33:29PM +0100, Jeroen Massar wrote:
> 
> 8<-----------------
> Propose a new WG to write a new IPv6 over IPv4 tunneling protocol
> 1. Based on the tunneling requirements write one new protocol
> 2. Work on two components of the solution:
>    a) method to discover the tunnel end-point
>    b) specification of the tunnel set-up protocol
> ----------------->8
> 
> There are three components to "Tunneling", the third is the actual
> protocol, but you mention that in the first part, probably a rephrase
> would be better.

I think the word "configuration" is missing up there...

"Propose a new WG to write a new IPv6 over IPv4 tunneling configuration
 protocol"

The WG name would be something like v6tc WG

Tim



From owner-v6ops@ops.ietf.org  Wed Nov 10 08:39:07 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07119
	for <v6ops-archive@lists.ietf.org>; Wed, 10 Nov 2004 08:39:07 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CRsgK-000P8z-Pi
	for v6ops-data@psg.com; Wed, 10 Nov 2004 13:38:40 +0000
Received: from [213.197.29.32] (helo=noc.sixxs.net)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CRsgG-000P75-JS
	for v6ops@ops.ietf.org; Wed, 10 Nov 2004 13:38:36 +0000
Received: from localhost (localhost [127.0.0.1])
	by noc.sixxs.net (Postfix) with ESMTP id B774324016;
	Wed, 10 Nov 2004 14:38:35 +0100 (CET)
Received: from noc.sixxs.net ([127.0.0.1])
	by localhost (noc [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
	id 11327-08; Wed, 10 Nov 2004 14:38:32 +0100 (CET)
Received: from firenze.zurich.ibm.com (pat.zurich.ibm.com [195.176.20.45])
	(using SSLv3 with cipher RC4-MD5 (128/128 bits))
	(No client certificate requested)
	by noc.sixxs.net (Postfix) with ESMTP id 202822400B;
	Wed, 10 Nov 2004 14:35:49 +0100 (CET)
Subject: Re: updated v6ops agenda, presentation of way forward
From: Jeroen Massar <jeroen@unfix.org>
To: Pekka Savola <pekkas@netcore.fi>, "Bound, Jim" <jim.bound@hp.com>
Cc: v6ops@ops.ietf.org
In-Reply-To: <Pine.LNX.4.61.0411101452180.17270@netcore.fi>
References: <0I6Y008BHPNPXF@ms13.samsung.com>
	 <1100090009.30064.21.camel@firenze.zurich.ibm.com>
	 <Pine.LNX.4.61.0411101452180.17270@netcore.fi>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-2SnRdtzw+CBmki7i63MI"
Organization: Unfix
Date: Wed, 10 Nov 2004 14:35:21 +0100
Message-Id: <1100093721.30064.46.camel@firenze.zurich.ibm.com>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.2 (2.0.2-4) 
X-Virus-Scanned: noc.sixxs.net - http://www.sixxs.net
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk


--=-2SnRdtzw+CBmki7i63MI
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Wed, 2004-11-10 at 15:05 +0200, Pekka Savola wrote:
<SNIP>
> > next to that there are a number of drafts which have been submitted=20
> > for quite some time already surrounding this subject and=20
> > specifically for doing IPv6 over NAT- crippled IPv4 hosts. I don't=20
> > recall seeing a draft about Hexago's v6udpv4 protocol though, not=20
> > that it is complex but still.
>=20
> Yes, there have definitely been drafts :).  It seemed that these have=20
> some short-comings though, so that trying to merge the best parts of=20
> each to one proposal might make sense.

I haven't seen any comments indicating such on both the AYIYA nor on the
heartbeat drafts which I submitted. Then again apparently a lot of
people seem to ignore anything with -00 or -01. I did get quite a number
of positive comments though.

On Wed, 2004-11-10 at 08:10 -0500, Bound, Jim wrote:=20
> Thanks for my answer I agree and makes sense to get this done.  FYI
> early adopters are setting up tunnels now and using multiple approaches
> to discover TEPS.  The ones I am seeing dominant right now are private
> company/provider tunnel brokers with set up and hand configured TEPs,

Most tunnel brokers system (the ones I know at least) are fully automated.
Though the automation is mostly simply typing in what otherwise the user
had to type thus making IPv6 connectivity possible for the not so computer-=
freaky.

Also I think that many of the 'early adopters' are not 'early adopters' any=
 more,
they are mostly around for some 5+ years already. (Freenet6 is around since=
 1999)
Many entities already have a lot of experience in deploying IPv6 even
though in some areas of this globe only since some goverment agency
started donating big money they started working on it.

> mannual tunnel configured TEPs at edges, and to lesser degree DHCPv6
> with custom extensions.  So a TEP discovery solution is required for
> sure.

DHCPv6? I still have to see that working ;)
Would be nice option to have though, create a tunnel, use RA or DHCP to
get the prefix on the tunnel and possibly also=20

The main reason I know that we are not using RA's is that we want the
host to be ::2/64, so we can ping6 it for latency and availability and
then we can also correctly point the prefix to that ip. DHCPv6 could solve
that, but how many hosts/router platforms have that functionality again?
DHCPv6-PD would be really nice to do though.

Greets,
 Jeroen


--=-2SnRdtzw+CBmki7i63MI
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Jeroen Massar / http://unfix.org/~jeroen/

iD8DBQBBkhkZKaooUjM+fCMRAjspAJ9KH4Aig4o4GCLA7nAlD8QffJ/wRACghKQb
M7BlsWf2VTjmXEH9hKVWxQs=
=NMlT
-----END PGP SIGNATURE-----

--=-2SnRdtzw+CBmki7i63MI--




From owner-v6ops@ops.ietf.org  Wed Nov 10 08:45:30 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07650
	for <v6ops-archive@lists.ietf.org>; Wed, 10 Nov 2004 08:45:30 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CRsma-00009d-Oc
	for v6ops-data@psg.com; Wed, 10 Nov 2004 13:45:08 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CRsmQ-00006L-4C
	for v6ops@ops.ietf.org; Wed, 10 Nov 2004 13:44:58 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id iAADinQ18733;
	Wed, 10 Nov 2004 15:44:49 +0200
Date: Wed, 10 Nov 2004 15:44:49 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: Jeroen Massar <jeroen@unfix.org>
cc: "Bound, Jim" <jim.bound@hp.com>, v6ops@ops.ietf.org
Subject: Re: updated v6ops agenda, presentation of way forward
In-Reply-To: <1100093721.30064.46.camel@firenze.zurich.ibm.com>
Message-ID: <Pine.LNX.4.61.0411101544130.18590@netcore.fi>
References: <0I6Y008BHPNPXF@ms13.samsung.com>  <1100090009.30064.21.camel@firenze.zurich.ibm.com>
  <Pine.LNX.4.61.0411101452180.17270@netcore.fi> <1100093721.30064.46.camel@firenze.zurich.ibm.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

Let's try to avoid going into the gritty proto

On Wed, 10 Nov 2004, Jeroen Massar wrote:
>> mannual tunnel configured TEPs at edges, and to lesser degree DHCPv6
>> with custom extensions.  So a TEP discovery solution is required for
>> sure.
>
> DHCPv6? I still have to see that working ;)
> Would be nice option to have though, create a tunnel, use RA or DHCP to
> get the prefix on the tunnel and possibly also
>
> The main reason I know that we are not using RA's is that we want the
> host to be ::2/64, so we can ping6 it for latency and availability and
> then we can also correctly point the prefix to that ip. DHCPv6 could solve
> that, but how many hosts/router platforms have that functionality again?
> DHCPv6-PD would be really nice to do though.
>

-- 
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 owner-v6ops@ops.ietf.org  Wed Nov 10 08:48:22 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08052
	for <v6ops-archive@lists.ietf.org>; Wed, 10 Nov 2004 08:48:22 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CRspS-0000ab-KB
	for v6ops-data@psg.com; Wed, 10 Nov 2004 13:48:06 +0000
Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CRspR-0000aF-Hz
	for v6ops@ops.ietf.org; Wed, 10 Nov 2004 13:48:05 +0000
Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131])
	by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id iAADm4Gn021267
	for <v6ops@ops.ietf.org>; Wed, 10 Nov 2004 13:48:04 GMT
Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162])
	by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id NAA20171
	for <v6ops@ops.ietf.org>; Wed, 10 Nov 2004 13:48:03 GMT
Received: (from tjc@localhost)
	by login.ecs.soton.ac.uk (8.11.6/8.11.6) id iAADm3322800
	for v6ops@ops.ietf.org; Wed, 10 Nov 2004 13:48:03 GMT
Date: Wed, 10 Nov 2004 13:48:03 +0000
From: Tim Chown <tjc@ecs.soton.ac.uk>
To: v6ops@ops.ietf.org
Subject: Re: updated v6ops agenda, presentation of way forward
Message-ID: <20041110134803.GN21680@login.ecs.soton.ac.uk>
Mail-Followup-To: v6ops@ops.ietf.org
References: <0I6Y008BHPNPXF@ms13.samsung.com> <1100090009.30064.21.camel@firenze.zurich.ibm.com> <Pine.LNX.4.61.0411101452180.17270@netcore.fi> <1100093721.30064.46.camel@firenze.zurich.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1100093721.30064.46.camel@firenze.zurich.ibm.com>
User-Agent: Mutt/1.4i
X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information
X-ECS-MailScanner: Found to be clean
X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

On Wed, Nov 10, 2004 at 02:35:21PM +0100, Jeroen Massar wrote:
> 
> I haven't seen any comments indicating such on both the AYIYA nor on the
> heartbeat drafts which I submitted. Then again apparently a lot of
> people seem to ignore anything with -00 or -01. I did get quite a number
> of positive comments though.

As one guilty of having not read it (sorry!) I think the problem is people
have limited time, and the v6ops scope is so broad, with so many personal
drafts too.   

I'll try to circulate a list of v6ops related drafts soon so we can see the
diversity and volume... 

I agree ayiya should be on the table for discussion by the new WG, if the WG 
happens.   But the focus is on the configuration more than the tunneling itself,
as proposed.

I suspect we can draw a lot of experience from methods/tricks used by 
existing systems, e.g. heartbeat protocols to support dynamic IPv4 addresses 
on clients.

-- 
Tim



From owner-v6ops@ops.ietf.org  Wed Nov 10 09:16:04 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10512
	for <v6ops-archive@lists.ietf.org>; Wed, 10 Nov 2004 09:16:03 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CRtFc-0004UW-W0
	for v6ops-data@psg.com; Wed, 10 Nov 2004 14:15:08 +0000
Received: from [213.197.29.32] (helo=noc.sixxs.net)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CRtF6-0004P7-9L
	for v6ops@ops.ietf.org; Wed, 10 Nov 2004 14:14:36 +0000
Received: from localhost (localhost [127.0.0.1])
	by noc.sixxs.net (Postfix) with ESMTP id 662F624010;
	Wed, 10 Nov 2004 15:14:35 +0100 (CET)
Received: from noc.sixxs.net ([127.0.0.1])
	by localhost (noc [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
	id 13705-04; Wed, 10 Nov 2004 15:14:33 +0100 (CET)
Received: from firenze.zurich.ibm.com (pat.zurich.ibm.com [195.176.20.45])
	(using SSLv3 with cipher RC4-MD5 (128/128 bits))
	(No client certificate requested)
	by noc.sixxs.net (Postfix) with ESMTP id D455524018;
	Wed, 10 Nov 2004 15:14:28 +0100 (CET)
Subject: Re: updated v6ops agenda, presentation of way forward
From: Jeroen Massar <jeroen@unfix.org>
To: Tim Chown <tjc@ecs.soton.ac.uk>
Cc: v6ops@ops.ietf.org
In-Reply-To: <20041110133416.GJ21680@login.ecs.soton.ac.uk>
References: <0I6Y008BHPNPXF@ms13.samsung.com>
	 <1100090009.30064.21.camel@firenze.zurich.ibm.com>
	 <20041110133416.GJ21680@login.ecs.soton.ac.uk>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-c8VMikuMLrEisgxKeRN9"
Organization: Unfix
Date: Wed, 10 Nov 2004 15:13:47 +0100
Message-Id: <1100096027.30064.51.camel@firenze.zurich.ibm.com>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.2 (2.0.2-4) 
X-Virus-Scanned: noc.sixxs.net - http://www.sixxs.net
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk


--=-c8VMikuMLrEisgxKeRN9
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Wed, 2004-11-10 at 13:34 +0000, Tim Chown wrote:
> On Wed, Nov 10, 2004 at 01:33:29PM +0100, Jeroen Massar wrote:
> >=20
> > 8<-----------------
> > Propose a new WG to write a new IPv6 over IPv4 tunneling protocol
> > 1. Based on the tunneling requirements write one new protocol
> > 2. Work on two components of the solution:
> >    a) method to discover the tunnel end-point
> >    b) specification of the tunnel set-up protocol
> > ----------------->8
> >=20
> > There are three components to "Tunneling", the third is the actual
> > protocol, but you mention that in the first part, probably a rephrase
> > would be better.
>=20
> I think the word "configuration" is missing up there...

The 'set-up' is the configuration part, configuration is a bit clearer
indeed on what really is happening.

> "Propose a new WG to write a new IPv6 over IPv4 tunneling configuration
>  protocol"

"Propose a new WG to define a IPv6 over IPv4 tunnel configuration
protocol"

Would be a better formulation IMHO.

> The WG name would be something like v6tc WG

Sounds reasonable to me.

Greets,
 Jeroen


--=-c8VMikuMLrEisgxKeRN9
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Jeroen Massar / http://unfix.org/~jeroen/

iD8DBQBBkiIbKaooUjM+fCMRAgL0AJ44bvNtaW25HIFXRzli5iFhyGqHsACgwcyA
jXF7vaE/2WsOP3ECcDDtsys=
=UFeH
-----END PGP SIGNATURE-----

--=-c8VMikuMLrEisgxKeRN9--




From owner-v6ops@ops.ietf.org  Wed Nov 10 09:51:32 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14043
	for <v6ops-archive@lists.ietf.org>; Wed, 10 Nov 2004 09:51:32 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CRtnN-0008nm-K1
	for v6ops-data@psg.com; Wed, 10 Nov 2004 14:50:01 +0000
Received: from [202.81.18.186] (helo=ausmtp01.au.ibm.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CRtnM-0008mf-3E
	for v6ops@ops.ietf.org; Wed, 10 Nov 2004 14:50:00 +0000
Received: from sd0112e0.au.ibm.com (d23rh903.au.ibm.com [202.81.18.201])
	by ausmtp01.au.ibm.com (8.12.10/8.12.10) with ESMTP id iAAEosrJ232968;
	Thu, 11 Nov 2004 01:50:54 +1100
Received: from d23m0018.cn.ibm.com (d23av02.au.ibm.com [9.190.250.243])
	by sd0112e0.au.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iAAEpJrX124646;
	Thu, 11 Nov 2004 01:51:20 +1100
In-Reply-To: <Pine.LNX.4.61.0411101544130.18590@netcore.fi>
Subject: Re: updated v6ops agenda, presentation of way forward
To: Pekka Savola <pekkas@netcore.fi>
Cc: Jeroen Massar <jeroen@unfix.org>, "Bound, Jim" <jim.bound@hp.com>,
        owner-v6ops@ops.ietf.org, v6ops@ops.ietf.org
X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004
Message-ID: <OF0F05EFFB.E8E16619-ON48256F48.0051428B-48256F48.00517283@cn.ibm.com>
From: Xiao Bing Guo <guoxb@cn.ibm.com>
Date: Wed, 10 Nov 2004 22:46:45 +0800
X-MIMETrack: Serialize by Router on d23m0018/23/M/IBM(Release 6.0.2CF2HF259 | March 11, 2004) at
 10/11/2004 22:46:47
MIME-Version: 1.0
Content-type: multipart/alternative; 
	Boundary="0__=C7BBE5DBDFC2C41B8f9e8a93df938690918cC7BBE5DBDFC2C41B"
Content-Disposition: inline
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,HTML_MESSAGE 
	autolearn=ham version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

--0__=C7BBE5DBDFC2C41B8f9e8a93df938690918cC7BBE5DBDFC2C41B
Content-type: text/plain; charset=US-ASCII





Maybe I did not catch your words. Why should only one solution("at most one

solution") be standarded in the v6tc? I think the goal is to solve the
existing problems. Of course redundant mechanisms should be avoided.
However, is there possible to summarize an "omnipotent" solution? Why we
should guarantee such a limitation before beginning the work.

In addition, when I go through the justification for the IPv6 Tunnel
Configuration work, I find that there is already one and only one proposal
that could meet all the identified requirements. The sole survival is STEP.

I hope it is just a coincidence, or it can answer the question mentioned in

the 1st paragraph.


Best Wishes,

Guo, Lenny
--0__=C7BBE5DBDFC2C41B8f9e8a93df938690918cC7BBE5DBDFC2C41B
Content-type: text/html; charset=US-ASCII
Content-Disposition: inline

<html><body>
<p><tt>Maybe I did not catch your words. Why should only one solution(&quot;at most one <br>
solution&quot;) be standarded in the v6tc? I think the goal is to solve the <br>
existing problems. Of course redundant mechanisms should be avoided. <br>
However, is there possible to summarize an &quot;omnipotent&quot; solution? Why we <br>
should guarantee such a limitation before beginning the work.</tt><br>
<tt><br>
In addition, when I go through the justification for the IPv6 Tunnel <br>
Configuration work, I find that there is already one and only one proposal <br>
that could meet all the identified requirements. The sole survival is STEP. <br>
I hope it is just a coincidence, or it can answer the question mentioned in <br>
the 1st paragraph.</tt><br>
<br>
<br>
Best Wishes,<br>
<br>
Guo, Lenny<br>
</body></html>
--0__=C7BBE5DBDFC2C41B8f9e8a93df938690918cC7BBE5DBDFC2C41B--




From owner-v6ops@ops.ietf.org  Wed Nov 10 10:14:46 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17456
	for <v6ops-archive@lists.ietf.org>; Wed, 10 Nov 2004 10:14:45 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CRuAy-000CaE-F4
	for v6ops-data@psg.com; Wed, 10 Nov 2004 15:14:24 +0000
Received: from [213.197.29.32] (helo=noc.sixxs.net)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CRuAx-000CZv-A4
	for v6ops@ops.ietf.org; Wed, 10 Nov 2004 15:14:23 +0000
Received: from localhost (localhost [127.0.0.1])
	by noc.sixxs.net (Postfix) with ESMTP id 19DF32400B;
	Wed, 10 Nov 2004 16:10:57 +0100 (CET)
Received: from noc.sixxs.net ([127.0.0.1])
	by localhost (noc [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
	id 16318-06; Wed, 10 Nov 2004 16:10:40 +0100 (CET)
Received: from firenze.zurich.ibm.com (pat.zurich.ibm.com [195.176.20.45])
	(using SSLv3 with cipher RC4-MD5 (128/128 bits))
	(No client certificate requested)
	by noc.sixxs.net (Postfix) with ESMTP id CC4AF24016;
	Wed, 10 Nov 2004 16:09:22 +0100 (CET)
Subject: Re: updated v6ops agenda, presentation of way forward
From: Jeroen Massar <jeroen@unfix.org>
To: Xiao Bing Guo <guoxb@cn.ibm.com>
Cc: Pekka Savola <pekkas@netcore.fi>, v6ops@ops.ietf.org
In-Reply-To: <OF0F05EFFB.E8E16619-ON48256F48.0051428B-48256F48.00517283@cn.ibm.com>
References: 
	 <OF0F05EFFB.E8E16619-ON48256F48.0051428B-48256F48.00517283@cn.ibm.com>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-yhUaVFVRp1kOhK3y++cJ"
Organization: Unfix
Date: Wed, 10 Nov 2004 16:08:40 +0100
Message-Id: <1100099320.30064.63.camel@firenze.zurich.ibm.com>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.2 (2.0.2-4) 
X-Virus-Scanned: noc.sixxs.net - http://www.sixxs.net
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk


--=-yhUaVFVRp1kOhK3y++cJ
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Wed, 2004-11-10 at 22:46 +0800, Xiao Bing Guo wrote:

> In addition, when I go through the justification for the IPv6 Tunnel=20
> Configuration work, I find that there is already one and only one
> proposal that could meet all the identified requirements. The sole
> survival is STEP. I hope it is just a coincidence, or it can answer
> the question mentioned in the 1st paragraph.

If you mean STEP as in:
http://www.netcore.fi/pekkas/ietf/draft-savola-v6ops-conftun-
setup-02.txt (because it has expired from the id-dir already)

this primarly only defines the problem and mentions some of the various
solutions that can be taken, but no final word is given on actually
doing it, let alone any implementation.

The appendices name a number of other protocols which actually do the
work. IMHO it thus fills some gap between the other problem statements
and solutions documents; While the real problem is more: who are you are
trying to give connectivity, what do you have now and how would you like
to do it. And there is no single solution for that problem, especially
when considering that some ISP's want to use it as an upgrade path to
native lines, without having to renumber their clients later on and of
course with as less possible changes in their infrastructure. Custom
solutions based on a number of predefined solutions is thus probably the
answer, but a single solution, not IMHO ;)

Greets,
 Jeroen


--=-yhUaVFVRp1kOhK3y++cJ
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Jeroen Massar / http://unfix.org/~jeroen/

iD8DBQBBki74KaooUjM+fCMRAofFAKCRy2ExYsujqlIjJ72stgLBxJqpPACfdwTe
FIvM1YTgIY8CZfHs2r7QC/w=
=5Aw/
-----END PGP SIGNATURE-----

--=-yhUaVFVRp1kOhK3y++cJ--




From owner-v6ops@ops.ietf.org  Wed Nov 10 11:33:34 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28036
	for <v6ops-archive@lists.ietf.org>; Wed, 10 Nov 2004 11:33:34 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CRvO1-000MBE-2r
	for v6ops-data@psg.com; Wed, 10 Nov 2004 16:31:57 +0000
Received: from [213.172.48.142] (helo=consulintel.es)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CRvO0-000MAo-4P
	for v6ops@ops.ietf.org; Wed, 10 Nov 2004 16:31:56 +0000
Received: from [130.129.135.232] ([130.129.135.232])
	by consulintel.es (consulintel.es [127.0.0.1])
	(MDaemon.PRO.v7.2.0.R)
	with ESMTP id md50000573044.msg
	for <v6ops@ops.ietf.org>; Wed, 10 Nov 2004 17:37:28 +0100
User-Agent: Microsoft-Entourage/10.1.4.030702.0
Date: Wed, 10 Nov 2004 11:31:41 -0500
Subject: FW: Mail exploder for new WG v6tc
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: <v6ops@ops.ietf.org>
Message-ID: <BDB7AC9D.4F2F1%jordi.palet@consulintel.es>
In-Reply-To: <BDB7A8E8.4F2D0%jordi.palet@consulintel.es>
Mime-version: 1.0
X-Priority: 1
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Spam-Processed: consulintel.es, Wed, 10 Nov 2004 17:37:28 +0100
	(not processed: message from valid local sender)
X-MDRemoteIP: 130.129.135.232
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ops.ietf.org
Reply-To: jordi.palet@consulintel.es
X-MDAV-Processed: consulintel.es, Wed, 10 Nov 2004 17:37:33 +0100
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-3.0 required=5.0 tests=AWL,BAYES_00,PRIORITY_NO_NAME,
	X_PRIORITY_HIGH autolearn=no version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit



------ Mensaje reenviado
De: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
Fecha: Wed, 10 Nov 2004 11:15:52 -0500
Para: <v6ops@ops.ietf.org>
CC: <david.kessens@nokia.com>, <bwijnen@lucent.com>, <narten@us.ibm.com>,
<margaret@thingmagic.com>
Asunto: Mail exploder for new WG v6tc

Hi all,

Following the request of keep moving and start to work, done by some IDs in
the v6ops meeting, after the discussion about the new focused WG in the
Internet area, I just created a mailing list for it.

The mailing list is v6tc@v6ops.euro6ix.net

To subscribe send an email to:

listserv@v6ops.euro6ix.net

with body

subscribe v6tc@v6ops.euro6ix.net


Let's start to work ?

I think the most important issue is to provide inputs on the proposed
chapter (see below the available documents).

Regards,
Jordi

PS: Related documents for those that didn't followed the discussion:
   http://netcore.fi/pekkas/ietf/61/v6tc-charter.txt
   http://netcore.fi/pekkas/ietf/61/v6tc-justification.txt



------ Fin del mensaje reenviado



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






From owner-v6ops@ops.ietf.org  Wed Nov 10 11:37:22 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28373
	for <v6ops-archive@lists.ietf.org>; Wed, 10 Nov 2004 11:37:22 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CRvSw-000MpR-KA
	for v6ops-data@psg.com; Wed, 10 Nov 2004 16:37:02 +0000
Received: from [213.172.48.142] (helo=consulintel.es)
 	by psg.com with esmtp (Exim 4.41 (FreeBSD))
 	id 1CRvAf-000KZ6-24
 	for v6ops@ops.ietf.org; Wed, 10 Nov 2004 16:18:09 +0000
Received: from [130.129.135.232] ([130.129.135.232])
 	by consulintel.es (consulintel.es [127.0.0.1])
 	(MDaemon.PRO.v7.2.0.R)
 	with ESMTP id md50000573005.msg
 	for <v6ops@ops.ietf.org>; Wed, 10 Nov 2004 17:23:44 +0100
User-Agent: Microsoft-Entourage/10.1.4.030702.0
Date: Wed, 10 Nov 2004 11:15:52 -0500
Subject: Mail exploder for new WG v6tc
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: <v6ops@ops.ietf.org>
CC: <david.kessens@nokia.com>, <bwijnen@lucent.com>, <narten@us.ibm.com>,
        <margaret@thingmagic.com>
Message-ID: <BDB7A8E8.4F2D0%jordi.palet@consulintel.es>
Mime-version: 1.0
X-Priority: 1
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Spam-Processed: consulintel.es, Wed, 10 Nov 2004 17:23:44 +0100
 	(not processed: message from valid local sender)
X-MDRemoteIP: 130.129.135.232
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ops.ietf.org
Reply-To: jordi.palet@consulintel.es
X-MDAV-Processed: consulintel.es, Wed, 10 Nov 2004 17:23:45 +0100
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-3.6 required=5.0 tests=AWL,BAYES_00,PRIORITY_NO_NAME,
 	X_PRIORITY_HIGH autolearn=no version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi all,

Following the request of keep moving and start to work, done by some IDs in
the v6ops meeting, after the discussion about the new focused WG in the
Internet area, I just created a mailing list for it.

The mailing list is v6tc@v6ops.euro6ix.net

To subscribe send an email to:

listserv@v6ops.euro6ix.net

with body

subscribe v6tc@v6ops.euro6ix.net


Let's start to work ?

I think the most important issue is to provide inputs on the proposed
chapter (see below the available documents).

Regards,
Jordi

PS: Related documents for those that didn't followed the discussion:
    http://netcore.fi/pekkas/ietf/61/v6tc-charter.txt
    http://netcore.fi/pekkas/ietf/61/v6tc-justification.txt



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






From owner-v6ops@ops.ietf.org  Wed Nov 10 11:38:22 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28445
	for <v6ops-archive@lists.ietf.org>; Wed, 10 Nov 2004 11:38:22 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CRvU0-000Mxw-0F
	for v6ops-data@psg.com; Wed, 10 Nov 2004 16:38:08 +0000
Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CRvTy-000MxR-R8
	for v6ops@ops.ietf.org; Wed, 10 Nov 2004 16:38:07 +0000
Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131])
	by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id iAAGc5Gn026272
	for <v6ops@ops.ietf.org>; Wed, 10 Nov 2004 16:38:06 GMT
Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162])
	by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id QAA07033
	for <v6ops@ops.ietf.org>; Wed, 10 Nov 2004 16:38:04 GMT
Received: (from tjc@localhost)
	by login.ecs.soton.ac.uk (8.11.6/8.11.6) id iAAGc4026921
	for v6ops@ops.ietf.org; Wed, 10 Nov 2004 16:38:04 GMT
Date: Wed, 10 Nov 2004 16:38:04 +0000
From: Tim Chown <tjc@ecs.soton.ac.uk>
To: v6ops@ops.ietf.org
Subject: Jabber log of IETF61 v6ops session
Message-ID: <20041110163804.GA26894@login.ecs.soton.ac.uk>
Mail-Followup-To: v6ops@ops.ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4i
X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information
X-ECS-MailScanner: Found to be clean
X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

Can be found at:

http://www.xmpp.org/ietf-logs/v6ops@ietf.xmpp.org/2004-11-10.html

-- 
Tim



From owner-v6ops@ops.ietf.org  Wed Nov 10 11:43:02 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28779
	for <v6ops-archive@lists.ietf.org>; Wed, 10 Nov 2004 11:43:01 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CRvYY-000NjW-Vw
	for v6ops-data@psg.com; Wed, 10 Nov 2004 16:42:50 +0000
Received: from [213.197.29.32] (helo=noc.sixxs.net)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CRvYV-000Nhq-0l
	for v6ops@ops.ietf.org; Wed, 10 Nov 2004 16:42:47 +0000
Received: from localhost (localhost [127.0.0.1])
	by noc.sixxs.net (Postfix) with ESMTP id 92D0024018;
	Wed, 10 Nov 2004 17:42:42 +0100 (CET)
Received: from noc.sixxs.net ([127.0.0.1])
	by localhost (noc [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
	id 21503-05; Wed, 10 Nov 2004 17:42:31 +0100 (CET)
Received: from firenze.zurich.ibm.com (pat.zurich.ibm.com [195.176.20.45])
	(using SSLv3 with cipher RC4-MD5 (128/128 bits))
	(No client certificate requested)
	by noc.sixxs.net (Postfix) with ESMTP id CD3B524010;
	Wed, 10 Nov 2004 17:40:56 +0100 (CET)
Subject: Re: FW: Mail exploder for new WG v6tc
From: Jeroen Massar <jeroen@unfix.org>
To: Jordi Palet <jordi.palet@consulintel.es>
Cc: v6ops@ops.ietf.org
In-Reply-To: <BDB7AC9D.4F2F1%jordi.palet@consulintel.es>
References: <BDB7AC9D.4F2F1%jordi.palet@consulintel.es>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-ifD0fZmYoBaygrcLD0Vc"
Organization: Unfix
Date: Wed, 10 Nov 2004 17:40:41 +0100
Message-Id: <1100104841.30064.95.camel@firenze.zurich.ibm.com>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.2 (2.0.2-4) 
X-Virus-Scanned: noc.sixxs.net - http://www.sixxs.net
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk


--=-ifD0fZmYoBaygrcLD0Vc
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Wed, 2004-11-10 at 11:31 -0500, JORDI PALET MARTINEZ wrote:
> Following the request of keep moving and start to work, done by some IDs =
in
> the v6ops meeting, after the discussion about the new focused WG in the
> Internet area, I just created a mailing list for it.

If and when there will be a new WG, it will be a IETF WG and as such can
easily get mail hosting done at one of the ietf servers.

Greets,
 Jeroen


--=-ifD0fZmYoBaygrcLD0Vc
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Jeroen Massar / http://unfix.org/~jeroen/

iD8DBQBBkkSJKaooUjM+fCMRAseYAKCnw0b1RNvle7BSDs7TDbuTUzf8NgCeIsll
Q0hMb0iS10u51t3oV/kR9m0=
=xuoq
-----END PGP SIGNATURE-----

--=-ifD0fZmYoBaygrcLD0Vc--




From owner-v6ops@ops.ietf.org  Wed Nov 10 11:52:07 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29907
	for <v6ops-archive@lists.ietf.org>; Wed, 10 Nov 2004 11:52:06 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CRvgx-000PA2-Ua
	for v6ops-data@psg.com; Wed, 10 Nov 2004 16:51:31 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CRvgl-000P7b-Mg
	for v6ops@ops.ietf.org; Wed, 10 Nov 2004 16:51:20 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id iAAGpAm23995;
	Wed, 10 Nov 2004 18:51:10 +0200
Date: Wed, 10 Nov 2004 18:51:10 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
cc: v6ops@ops.ietf.org, david.kessens@nokia.com, bwijnen@lucent.com,
        narten@us.ibm.com, margaret@thingmagic.com
Subject: Re: Mail exploder for new WG v6tc
In-Reply-To: <BDB7A8E8.4F2D0%jordi.palet@consulintel.es>
Message-ID: <Pine.LNX.4.61.0411101840050.23523@netcore.fi>
References: <BDB7A8E8.4F2D0%jordi.palet@consulintel.es>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

On Wed, 10 Nov 2004, JORDI PALET MARTINEZ wrote:
> Following the request of keep moving and start to work, done by some IDs in
> the v6ops meeting, after the discussion about the new focused WG in the
> Internet area, I just created a mailing list for it.
>
> The mailing list is v6tc@v6ops.euro6ix.net

As soon as agree on a name (for now, I suggest "v6tc"), let's create 
it at @ietf.org.  If you think the name is bad, speak up and offer a 
suggestion.

-- 
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 owner-v6ops@ops.ietf.org  Wed Nov 10 12:04:03 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01420
	for <v6ops-archive@lists.ietf.org>; Wed, 10 Nov 2004 12:04:02 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CRvsX-0001E3-Le
	for v6ops-data@psg.com; Wed, 10 Nov 2004 17:03:29 +0000
Received: from [213.172.48.142] (helo=consulintel.es)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CRvsQ-0001D5-BB
	for v6ops@ops.ietf.org; Wed, 10 Nov 2004 17:03:22 +0000
Received: from [130.129.135.232] ([130.129.135.232])
	by consulintel.es (consulintel.es [127.0.0.1])
	(MDaemon.PRO.v7.2.0.R)
	with ESMTP id md50000573178.msg
	for <v6ops@ops.ietf.org>; Wed, 10 Nov 2004 18:08:54 +0100
User-Agent: Microsoft-Entourage/10.1.4.030702.0
Date: Wed, 10 Nov 2004 11:57:57 -0500
Subject: Re: Mail exploder for new WG v6tc
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: <v6ops@ops.ietf.org>
CC: <david.kessens@nokia.com>, <bwijnen@lucent.com>, <narten@us.ibm.com>,
        <margaret@thingmagic.com>
Message-ID: <BDB7B2C5.4F30E%jordi.palet@consulintel.es>
In-Reply-To: <Pine.LNX.4.61.0411101840050.23523@netcore.fi>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Spam-Processed: consulintel.es, Wed, 10 Nov 2004 18:08:54 +0100
	(not processed: message from valid local sender)
X-MDRemoteIP: 130.129.135.232
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ops.ietf.org
Reply-To: jordi.palet@consulintel.es
X-MDAV-Processed: consulintel.es, Wed, 10 Nov 2004 18:08:59 +0100
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

No problem with that, but only if this means is created *today*, otherwise,
we use this one meanwhile.

Somebody know if that's possible (I mean creating the list at @ietf.org).

Regards,
Jordi


> De: Pekka Savola <pekkas@netcore.fi>
> Responder a: owner-v6ops@ops.ietf.org
> Fecha: Wed, 10 Nov 2004 18:51:10 +0200 (EET)
> Para: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
> CC: v6ops@ops.ietf.org, david.kessens@nokia.com, bwijnen@lucent.com,
> narten@us.ibm.com, margaret@thingmagic.com
> Asunto: Re: Mail exploder for new WG v6tc
> 
> On Wed, 10 Nov 2004, JORDI PALET MARTINEZ wrote:
>> Following the request of keep moving and start to work, done by some IDs in
>> the v6ops meeting, after the discussion about the new focused WG in the
>> Internet area, I just created a mailing list for it.
>> 
>> The mailing list is v6tc@v6ops.euro6ix.net
> 
> As soon as agree on a name (for now, I suggest "v6tc"), let's create
> it at @ietf.org.  If you think the name is bad, speak up and offer a
> suggestion.
> 
> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> 
> 



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






From owner-v6ops@ops.ietf.org  Wed Nov 10 12:17:33 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02544
	for <v6ops-archive@lists.ietf.org>; Wed, 10 Nov 2004 12:17:33 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CRw5i-0002ze-2K
	for v6ops-data@psg.com; Wed, 10 Nov 2004 17:17:06 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CRw5g-0002zI-4y
	for v6ops@ops.ietf.org; Wed, 10 Nov 2004 17:17:05 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id iAAHH2324748
	for <v6ops@ops.ietf.org>; Wed, 10 Nov 2004 19:17:02 +0200
Date: Wed, 10 Nov 2004 19:17:02 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: v6ops@ops.ietf.org
Subject: send in v6ops session minutes, presentations
Message-ID: <Pine.LNX.4.61.0411101909230.24540@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

Hi,

(co-chir hat on)

Minute-takers: please send in the minutes this week (they don't have 
to be perfect, because they're going to be merged/edited in any case).

Presenters: please send in the slides, preferably in pdf, but ppt is 
also acceptable (these will be converted to pdf).

I'll start collecting these temporarily at 
http://www.netcore.fi/pekkas/ietf/61/, but I'll send a separate 
heads-up when there's actually significant amount of material there 
(likely next week).

(hat off)

-- 
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 owner-v6ops@ops.ietf.org  Wed Nov 10 13:16:15 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07950
	for <v6ops-archive@lists.ietf.org>; Wed, 10 Nov 2004 13:16:14 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CRwzk-000ABi-5y
	for v6ops-data@psg.com; Wed, 10 Nov 2004 18:15:00 +0000
Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CRwzj-000ABP-3q
	for v6ops@ops.ietf.org; Wed, 10 Nov 2004 18:14:59 +0000
Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131])
	by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id iAAIEwGn029011
	for <v6ops@ops.ietf.org>; Wed, 10 Nov 2004 18:14:58 GMT
Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162])
	by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id SAA11990
	for <v6ops@ops.ietf.org>; Wed, 10 Nov 2004 18:14:55 GMT
Received: (from tjc@localhost)
	by login.ecs.soton.ac.uk (8.11.6/8.11.6) id iAAIEsD30293
	for v6ops@ops.ietf.org; Wed, 10 Nov 2004 18:14:54 GMT
Date: Wed, 10 Nov 2004 18:14:54 +0000
From: Tim Chown <tjc@ecs.soton.ac.uk>
To: v6ops@ops.ietf.org
Subject: Ops area open meeting today
Message-ID: <20041110181454.GB29882@login.ecs.soton.ac.uk>
Mail-Followup-To: v6ops@ops.ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4i
X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information
X-ECS-MailScanner: Found to be clean
X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

For info:

1pm-3pm in International E has a 15 min slot on v6ops future, which David
Kessens is presenting.  I assume this will summarise consensus reached
in the room thismorning (spin out v6tc, recharter v6ops with narrower focus).

This is after a 15min slot on multi6 WG future.

-- 
Tim



From owner-v6ops@ops.ietf.org  Wed Nov 10 13:28:03 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09319
	for <v6ops-archive@lists.ietf.org>; Wed, 10 Nov 2004 13:28:03 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CRxBz-000C7S-0I
	for v6ops-data@psg.com; Wed, 10 Nov 2004 18:27:39 +0000
Received: from [193.180.251.53] (helo=eagle.ericsson.se)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CRxBx-000C6z-Qv
	for v6ops@ops.ietf.org; Wed, 10 Nov 2004 18:27:38 +0000
Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118])
	by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id iAAIRaR2021532
	for <v6ops@ops.ietf.org>; Wed, 10 Nov 2004 19:27:37 +0100
Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211);
	 Wed, 10 Nov 2004 19:27:36 +0100
Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id WHLPPJWB; Wed, 10 Nov 2004 19:27:36 +0100
Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <J4NDFB51>; Wed, 10 Nov 2004 19:27:36 +0100
Message-ID: <C26BB8276599A44B85D52F9CE41035E1050B9839@esealnt944.al.sw.ericsson.se>
X-Sybari-Trust: 8feaa2d6 bfd556f1 425c8a31 00000139
From: "Karen E. Nielsen (AH/LMD)" <karen.e.nielsen@ericsson.com>
To: "'Tim Chown'" <tjc@ecs.soton.ac.uk>, v6ops@ops.ietf.org
Subject: RE: Ops area open meeting today
Date: Wed, 10 Nov 2004 19:27:35 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
X-OriginalArrivalTime: 10 Nov 2004 18:27:36.0708 (UTC) FILETIME=[F3F06440:01C4C752]
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

Any idea of when exactly ?

Karen

> -----Original Message-----
> From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On
> Behalf Of Tim Chown
> Sent: Wednesday, November 10, 2004 7:15 PM
> To: v6ops@ops.ietf.org
> Subject: Ops area open meeting today
> 
> 
> For info:
> 
> 1pm-3pm in International E has a 15 min slot on v6ops future, 
> which David
> Kessens is presenting.  I assume this will summarise consensus reached
> in the room thismorning (spin out v6tc, recharter v6ops with 
> narrower focus).
> 
> This is after a 15min slot on multi6 WG future.
> 
> -- 
> Tim
> 



From owner-v6ops@ops.ietf.org  Wed Nov 10 14:18:17 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15504
	for <v6ops-archive@lists.ietf.org>; Wed, 10 Nov 2004 14:18:17 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CRxxR-000J3r-Jo
	for v6ops-data@psg.com; Wed, 10 Nov 2004 19:16:41 +0000
Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CRxxQ-000J3V-Io
	for v6ops@ops.ietf.org; Wed, 10 Nov 2004 19:16:40 +0000
Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131])
	by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id iAAJGdGn000297
	for <v6ops@ops.ietf.org>; Wed, 10 Nov 2004 19:16:39 GMT
Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162])
	by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id TAA13843
	for <v6ops@ops.ietf.org>; Wed, 10 Nov 2004 19:16:36 GMT
Received: (from tjc@localhost)
	by login.ecs.soton.ac.uk (8.11.6/8.11.6) id iAAJGaO32353
	for v6ops@ops.ietf.org; Wed, 10 Nov 2004 19:16:36 GMT
Date: Wed, 10 Nov 2004 19:16:36 +0000
From: Tim Chown <tjc@ecs.soton.ac.uk>
To: v6ops@ops.ietf.org
Subject: Re: Ops area open meeting today
Message-ID: <20041110191636.GV29882@login.ecs.soton.ac.uk>
Mail-Followup-To: v6ops@ops.ietf.org
References: <C26BB8276599A44B85D52F9CE41035E1050B9839@esealnt944.al.sw.ericsson.se>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <C26BB8276599A44B85D52F9CE41035E1050B9839@esealnt944.al.sw.ericsson.se>
User-Agent: Mutt/1.4i
X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information
X-ECS-MailScanner: Found to be clean
X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

Multi6 is up now, so v6ops in 10-15 mins I guess.

tim

On Wed, Nov 10, 2004 at 07:27:35PM +0100, Karen E. Nielsen (AH/LMD) wrote:
> Any idea of when exactly ?
> 
> Karen
> 
> > -----Original Message-----
> > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On
> > Behalf Of Tim Chown
> > Sent: Wednesday, November 10, 2004 7:15 PM
> > To: v6ops@ops.ietf.org
> > Subject: Ops area open meeting today
> > 
> > 
> > For info:
> > 
> > 1pm-3pm in International E has a 15 min slot on v6ops future, 
> > which David
> > Kessens is presenting.  I assume this will summarise consensus reached
> > in the room thismorning (spin out v6tc, recharter v6ops with 
> > narrower focus).
> > 
> > This is after a 15min slot on multi6 WG future.
> > 
> > -- 
> > Tim
> > 

-- 
Tim

North American IPv6 Task Force Technologist Seminar
More info at http://www.ipv6seminar.com/



From owner-v6ops@ops.ietf.org  Wed Nov 10 15:05:41 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20550
	for <v6ops-archive@lists.ietf.org>; Wed, 10 Nov 2004 15:05:41 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CRyia-000P1x-P3
	for v6ops-data@psg.com; Wed, 10 Nov 2004 20:05:24 +0000
Received: from [161.114.64.103] (helo=zmamail03.zma.compaq.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CRyiZ-000P1h-V6
	for v6ops@ops.ietf.org; Wed, 10 Nov 2004 20:05:24 +0000
Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186])
	by zmamail03.zma.compaq.com (Postfix) with ESMTP id 9074BCA;
	Wed, 10 Nov 2004 15:05:23 -0500 (EST)
Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211);
	 Wed, 10 Nov 2004 15:05:23 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: FW: Mail exploder for new WG v6tc
Date: Wed, 10 Nov 2004 15:05:29 -0500
Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B07C4CDE0@tayexc13.americas.cpqcorp.net>
Thread-Topic: FW: Mail exploder for new WG v6tc
Thread-Index: AcTHRGQi6c+X02e1SBKGPBQ4mwzM5AAHDktw
From: "Bound, Jim" <jim.bound@hp.com>
To: "Jeroen Massar" <jeroen@unfix.org>,
        "Jordi Palet" <jordi.palet@consulintel.es>
Cc: <v6ops@ops.ietf.org>
X-OriginalArrivalTime: 10 Nov 2004 20:05:23.0383 (UTC) FILETIME=[9CBFF470:01C4C760]
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

Exactly.
/jim=20

> -----Original Message-----
> From: owner-v6ops@ops.ietf.org=20
> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Jeroen Massar
> Sent: Wednesday, November 10, 2004 11:41 AM
> To: Jordi Palet
> Cc: v6ops@ops.ietf.org
> Subject: Re: FW: Mail exploder for new WG v6tc
>=20
> On Wed, 2004-11-10 at 11:31 -0500, JORDI PALET MARTINEZ wrote:
> > Following the request of keep moving and start to work,=20
> done by some=20
> > IDs in the v6ops meeting, after the discussion about the=20
> new focused=20
> > WG in the Internet area, I just created a mailing list for it.
>=20
> If and when there will be a new WG, it will be a IETF WG and=20
> as such can easily get mail hosting done at one of the ietf servers.
>=20
> Greets,
>  Jeroen
>=20
>=20



From owner-v6ops@ops.ietf.org  Wed Nov 10 15:05:49 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20581
	for <v6ops-archive@lists.ietf.org>; Wed, 10 Nov 2004 15:05:49 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CRyiE-000Owm-Lj
	for v6ops-data@psg.com; Wed, 10 Nov 2004 20:05:02 +0000
Received: from [161.114.64.105] (helo=zmamail05.zma.compaq.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CRyiD-000OwB-8E
	for v6ops@ops.ietf.org; Wed, 10 Nov 2004 20:05:01 +0000
Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186])
	by zmamail05.zma.compaq.com (Postfix) with ESMTP id 4C4EA6AC9;
	Wed, 10 Nov 2004 15:05:00 -0500 (EST)
Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211);
	 Wed, 10 Nov 2004 15:04:59 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Mail exploder for new WG v6tc
Date: Wed, 10 Nov 2004 15:05:06 -0500
Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B07C4CDDF@tayexc13.americas.cpqcorp.net>
Thread-Topic: Mail exploder for new WG v6tc
Thread-Index: AcTHQ6M1ErLDoq2xQymEeNzO3cq0iwAHNkpA
From: "Bound, Jim" <jim.bound@hp.com>
To: <jordi.palet@consulintel.es>, <v6ops@ops.ietf.org>
Cc: <david.kessens@nokia.com>, <bwijnen@lucent.com>, <narten@us.ibm.com>,
        <margaret@thingmagic.com>
X-OriginalArrivalTime: 10 Nov 2004 20:04:59.0977 (UTC) FILETIME=[8ECC7B90:01C4C760]
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

WHOOOOOOOOOOOOOOOOAAAAAAAAAAAAAAAAAAAAAAAAAAAAA  This needs some type of
IETF blessing ..........and this should be set up as list by IETF.

Slow down here.

/jim=20

> -----Original Message-----
> From: owner-v6ops@ops.ietf.org=20
> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of JORDI PALET MARTINEZ
> Sent: Wednesday, November 10, 2004 11:16 AM
> To: v6ops@ops.ietf.org
> Cc: david.kessens@nokia.com; bwijnen@lucent.com;=20
> narten@us.ibm.com; margaret@thingmagic.com
> Subject: Mail exploder for new WG v6tc
> Importance: High
>=20
> Hi all,
>=20
> Following the request of keep moving and start to work, done=20
> by some IDs in the v6ops meeting, after the discussion about=20
> the new focused WG in the Internet area, I just created a=20
> mailing list for it.
>=20
> The mailing list is v6tc@v6ops.euro6ix.net
>=20
> To subscribe send an email to:
>=20
> listserv@v6ops.euro6ix.net
>=20
> with body
>=20
> subscribe v6tc@v6ops.euro6ix.net
>=20
>=20
> Let's start to work ?
>=20
> I think the most important issue is to provide inputs on the=20
> proposed chapter (see below the available documents).
>=20
> Regards,
> Jordi
>=20
> PS: Related documents for those that didn't followed the discussion:
>     http://netcore.fi/pekkas/ietf/61/v6tc-charter.txt
>     http://netcore.fi/pekkas/ietf/61/v6tc-justification.txt
>=20
>=20
>=20
> **********************************
> Madrid 2003 Global IPv6 Summit
> Presentations and videos on line at:
> http://www.ipv6-es.com
>=20
> This electronic message contains information which may be=20
> privileged or confidential. The information is intended to be=20
> for the use of the individual(s) named above. If you are not=20
> the intended recipient be aware that any disclosure, copying,=20
> distribution or use of the contents of this information,=20
> including attached files, is prohibited.
>=20
>=20
>=20
>=20
>=20



From owner-v6ops@ops.ietf.org  Wed Nov 10 15:07:39 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21037
	for <v6ops-archive@lists.ietf.org>; Wed, 10 Nov 2004 15:07:39 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CRykc-000PMR-JF
	for v6ops-data@psg.com; Wed, 10 Nov 2004 20:07:30 +0000
Received: from [161.114.64.104] (helo=zmamail04.zma.compaq.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CRykb-000PM9-IQ
	for v6ops@ops.ietf.org; Wed, 10 Nov 2004 20:07:29 +0000
Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127])
	by zmamail04.zma.compaq.com (Postfix) with ESMTP id 2B520512B;
	Wed, 10 Nov 2004 15:07:29 -0500 (EST)
Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211);
	 Wed, 10 Nov 2004 15:07:28 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Mail exploder for new WG v6tc
Date: Wed, 10 Nov 2004 15:07:35 -0500
Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B07C4CDE2@tayexc13.americas.cpqcorp.net>
Thread-Topic: Mail exploder for new WG v6tc
Thread-Index: AcTHSELnn+PBFVXQQOaLY1mNy738oAAGGwiQ
From: "Bound, Jim" <jim.bound@hp.com>
To: <jordi.palet@consulintel.es>, <v6ops@ops.ietf.org>
Cc: <david.kessens@nokia.com>, <bwijnen@lucent.com>, <narten@us.ibm.com>,
        <margaret@thingmagic.com>
X-OriginalArrivalTime: 10 Nov 2004 20:07:28.0979 (UTC) FILETIME=[E79C6230:01C4C760]
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

No I will not contribute until there is a chair and valid IETF WG list
and charter.  YOu will have to rejustify everything you do here.  So be
ready for that ok.  Your jumping the gun here and this is not the IETF
way.  Fine for design list but realize it will all have to be discussed
again most likely as I said.

V6ops WG Chairs can you sit down with Jordi and explain to him our ways
here.

Thanks
/jim=20

> -----Original Message-----
> From: owner-v6ops@ops.ietf.org=20
> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of JORDI PALET MARTINEZ
> Sent: Wednesday, November 10, 2004 11:58 AM
> To: v6ops@ops.ietf.org
> Cc: david.kessens@nokia.com; bwijnen@lucent.com;=20
> narten@us.ibm.com; margaret@thingmagic.com
> Subject: Re: Mail exploder for new WG v6tc
>=20
> No problem with that, but only if this means is created=20
> *today*, otherwise, we use this one meanwhile.
>=20
> Somebody know if that's possible (I mean creating the list at=20
> @ietf.org).
>=20
> Regards,
> Jordi
>=20
>=20
> > De: Pekka Savola <pekkas@netcore.fi>
> > Responder a: owner-v6ops@ops.ietf.org
> > Fecha: Wed, 10 Nov 2004 18:51:10 +0200 (EET)
> > Para: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
> > CC: v6ops@ops.ietf.org, david.kessens@nokia.com,=20
> bwijnen@lucent.com,=20
> > narten@us.ibm.com, margaret@thingmagic.com
> > Asunto: Re: Mail exploder for new WG v6tc
> >=20
> > On Wed, 10 Nov 2004, JORDI PALET MARTINEZ wrote:
> >> Following the request of keep moving and start to work,=20
> done by some=20
> >> IDs in the v6ops meeting, after the discussion about the=20
> new focused=20
> >> WG in the Internet area, I just created a mailing list for it.
> >>=20
> >> The mailing list is v6tc@v6ops.euro6ix.net
> >=20
> > As soon as agree on a name (for now, I suggest "v6tc"),=20
> let's create=20
> > it at @ietf.org.  If you think the name is bad, speak up=20
> and offer a=20
> > suggestion.
> >=20
> > --=20
> > Pekka Savola                 "You each name yourselves king, yet the
> > Netcore Oy                    kingdom bleeds."
> > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> >=20
> >=20
>=20
>=20
>=20
> **********************************
> Madrid 2003 Global IPv6 Summit
> Presentations and videos on line at:
> http://www.ipv6-es.com
>=20
> This electronic message contains information which may be=20
> privileged or confidential. The information is intended to be=20
> for the use of the individual(s) named above. If you are not=20
> the intended recipient be aware that any disclosure, copying,=20
> distribution or use of the contents of this information,=20
> including attached files, is prohibited.
>=20
>=20
>=20
>=20
>=20



From owner-v6ops@ops.ietf.org  Wed Nov 10 15:37:30 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25564
	for <v6ops-archive@lists.ietf.org>; Wed, 10 Nov 2004 15:37:30 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CRzCA-0002ec-At
	for v6ops-data@psg.com; Wed, 10 Nov 2004 20:35:58 +0000
Received: from [213.172.48.142] (helo=consulintel.es)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CRzC9-0002eL-79
	for v6ops@ops.ietf.org; Wed, 10 Nov 2004 20:35:57 +0000
Received: from [130.129.135.232] ([130.129.135.232])
	by consulintel.es (consulintel.es [127.0.0.1])
	(MDaemon.PRO.v7.2.0.R)
	with ESMTP id md50000573676.msg
	for <v6ops@ops.ietf.org>; Wed, 10 Nov 2004 21:41:30 +0100
User-Agent: Microsoft-Entourage/10.1.4.030702.0
Date: Wed, 10 Nov 2004 15:35:40 -0500
Subject: Re: Mail exploder for new WG v6tc
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: <v6ops@ops.ietf.org>
Message-ID: <BDB7E5CC.4F42C%jordi.palet@consulintel.es>
In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B07C4CDE0@tayexc13.americas.cpqcorp.net>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Spam-Processed: consulintel.es, Wed, 10 Nov 2004 21:41:30 +0100
	(not processed: message from valid local sender)
X-MDRemoteIP: 130.129.135.232
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ops.ietf.org
Reply-To: jordi.palet@consulintel.es
X-MDAV-Processed: consulintel.es, Wed, 10 Nov 2004 21:41:33 +0100
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

I think both of you miss the point, so let me clarify.

1) One of the ADs asked at the end of the meeting to setup a mailing list to
move on with this work.
2) Several official WG, as I recall, have used non-IETF.org mail exploders.
3) This could be perfectly a temporary measure until the official one is
setup (I think that was the idea of 1).

Moreover, even if some people don't like this mail exploder, others are
willing to work and use it (more than 10 people registered already). I don't
see any problem on that, right ?

Anyway, I got some news some minutes ago. It seems that the official list
got already the approval, but I'm not sure if that one can be setup so
quickly, so I just tried to help.

Regards,
Jordi


> De: "Bound, Jim" <jim.bound@hp.com>
> Responder a: owner-v6ops@ops.ietf.org
> Fecha: Wed, 10 Nov 2004 15:05:29 -0500
> Para: "Jeroen Massar" <jeroen@unfix.org>, "Jordi Palet"
> <jordi.palet@consulintel.es>
> CC: <v6ops@ops.ietf.org>
> Asunto: RE: FW: Mail exploder for new WG v6tc
> 
> Exactly.
> /jim 
> 
>> -----Original Message-----
>> From: owner-v6ops@ops.ietf.org
>> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Jeroen Massar
>> Sent: Wednesday, November 10, 2004 11:41 AM
>> To: Jordi Palet
>> Cc: v6ops@ops.ietf.org
>> Subject: Re: FW: Mail exploder for new WG v6tc
>> 
>> On Wed, 2004-11-10 at 11:31 -0500, JORDI PALET MARTINEZ wrote:
>>> Following the request of keep moving and start to work,
>> done by some 
>>> IDs in the v6ops meeting, after the discussion about the
>> new focused 
>>> WG in the Internet area, I just created a mailing list for it.
>> 
>> If and when there will be a new WG, it will be a IETF WG and
>> as such can easily get mail hosting done at one of the ietf servers.
>> 
>> Greets,
>>  Jeroen
>> 
>> 
> 
> 



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






From owner-v6ops@ops.ietf.org  Wed Nov 10 16:49:31 2004
Received: from psg.com (psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08533
	for <v6ops-archive@lists.ietf.org>; Wed, 10 Nov 2004 16:49:30 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CS0HH-0001cS-I7
	for v6ops-data@psg.com; Wed, 10 Nov 2004 21:45:19 +0000
Received: from [161.114.64.105] (helo=zmamail05.zma.compaq.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CS0HE-0001bm-1S
	for v6ops@ops.ietf.org; Wed, 10 Nov 2004 21:45:16 +0000
Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186])
	by zmamail05.zma.compaq.com (Postfix) with ESMTP id E9816ADA3;
	Wed, 10 Nov 2004 16:30:19 -0500 (EST)
Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211);
	 Wed, 10 Nov 2004 16:30:19 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Mail exploder for new WG v6tc
Date: Wed, 10 Nov 2004 16:30:26 -0500
Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B07C4CE1A@tayexc13.americas.cpqcorp.net>
Thread-Topic: Mail exploder for new WG v6tc
Thread-Index: AcTHasCnYABvgPnqSFOQlm0e6CNoYwAAZyiw
From: "Bound, Jim" <jim.bound@hp.com>
To: "Pekka Savola" <pekkas@netcore.fi>
Cc: <jordi.palet@consulintel.es>, <v6ops@ops.ietf.org>,
        <david.kessens@nokia.com>, <bwijnen@lucent.com>, <narten@us.ibm.com>,
        <margaret@thingmagic.com>
X-OriginalArrivalTime: 10 Nov 2004 21:30:19.0708 (UTC) FILETIME=[7A656FC0:01C4C76C]
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

Ok that is fine then.  I just want to make sure we don't have to discuss
things twice that is all not mean't against jordi.=20
Thanks
/jim=20

> -----Original Message-----
> From: Pekka Savola [mailto:pekkas@netcore.fi]=20
> Sent: Wednesday, November 10, 2004 4:18 PM
> To: Bound, Jim
> Cc: jordi.palet@consulintel.es; v6ops@ops.ietf.org;=20
> david.kessens@nokia.com; bwijnen@lucent.com;=20
> narten@us.ibm.com; margaret@thingmagic.com
> Subject: RE: Mail exploder for new WG v6tc
>=20
> On Wed, 10 Nov 2004, Bound, Jim wrote:
> > No I will not contribute until there is a chair and valid=20
> IETF WG list=20
> > and charter. [...]
>=20
> Maybe that is a bit unfair statement, because there can't=20
> really be a charter or chair until the WG is approved .. at=20
> least officially :)
>=20
> In any case, I've requested and Margaret has approved the=20
> creation of v6tc@ietf.org mailing list, and it should be set=20
> up within one business day.
>=20
> I'm sure Jordi had good intentions here for getting down the=20
> path quickly, he probably just didn't know how easy it is to=20
> set up a mailing list at the IETF if there is clear community=20
> interest to do it
> :)
>=20
> I can send an explicit note when I get the ack that the list=20
> has been set up.
>=20
> (co-chair hat on)
> Can we drop this thread now?  Thanks :)
> (hat off)
>=20
> --=20
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>=20



From owner-v6ops@ops.ietf.org  Wed Nov 10 16:55:55 2004
Received: from psg.com (psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09097
	for <v6ops-archive@lists.ietf.org>; Wed, 10 Nov 2004 16:55:55 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CS0RA-0002wZ-AL
	for v6ops-data@psg.com; Wed, 10 Nov 2004 21:55:32 +0000
Received: from [62.189.30.6] (helo=tortoise.webcentre.net)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CS0R6-0002wE-PC
	for v6ops@ops.ietf.org; Wed, 10 Nov 2004 21:55:29 +0000
Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1])
	by tortoise.webcentre.net (8.13.1/8.13.1) with ESMTP id iAALQhlW006685
	for <v6ops@ops.ietf.org>; Wed, 10 Nov 2004 21:26:43 GMT
Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131])
	by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id iAALTIHP002190
	for <v6ops@ops.ietf.org>; Wed, 10 Nov 2004 21:29:32 GMT
Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162])
	by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id UAA15030
	for <v6ops@ops.ietf.org>; Wed, 10 Nov 2004 20:27:44 GMT
Received: (from tjc@localhost)
	by login.ecs.soton.ac.uk (8.11.6/8.11.6) id iAAKRiI02206
	for v6ops@ops.ietf.org; Wed, 10 Nov 2004 20:27:44 GMT
Date: Wed, 10 Nov 2004 20:27:44 +0000
From: Tim Chown <tjc@ecs.soton.ac.uk>
To: v6ops@ops.ietf.org
Subject: Re: Mail exploder for new WG v6tc
Message-ID: <20041110202744.GC1904@login.ecs.soton.ac.uk>
Mail-Followup-To: v6ops@ops.ietf.org
References: <9C422444DE99BC46B3AD3C6EAFC9711B07C4CDE2@tayexc13.americas.cpqcorp.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B07C4CDE2@tayexc13.americas.cpqcorp.net>
User-Agent: Mutt/1.4i
X-ECS-MailScanner: Found to be clean
X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk
X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

On Wed, Nov 10, 2004 at 03:07:35PM -0500, Bound, Jim wrote:
> No I will not contribute until there is a chair and valid IETF WG list
> and charter.  YOu will have to rejustify everything you do here.  So be
> ready for that ok.  Your jumping the gun here and this is not the IETF
> way.  Fine for design list but realize it will all have to be discussed
> again most likely as I said.
> 
> V6ops WG Chairs can you sit down with Jordi and explain to him our ways
> here.

Note there is a zct list for the zct draft folks and interested parties;
that can continue to be used as can v6ops list itself.   At this stage 
we need to make sure all discussion is very open though, so v6ops is I
think the only place to do that.

Tim



From owner-v6ops@ops.ietf.org  Wed Nov 10 17:24:28 2004
Received: from psg.com (psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11860
	for <v6ops-archive@lists.ietf.org>; Wed, 10 Nov 2004 17:24:28 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CS0sZ-0006IN-Bh
	for v6ops-data@psg.com; Wed, 10 Nov 2004 22:23:51 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CS0sS-0006HP-L9
	for v6ops@ops.ietf.org; Wed, 10 Nov 2004 22:23:48 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id iAALHc630924;
	Wed, 10 Nov 2004 23:17:38 +0200
Date: Wed, 10 Nov 2004 23:17:38 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: "Bound, Jim" <jim.bound@hp.com>
cc: jordi.palet@consulintel.es, v6ops@ops.ietf.org, david.kessens@nokia.com,
        bwijnen@lucent.com, narten@us.ibm.com, margaret@thingmagic.com
Subject: RE: Mail exploder for new WG v6tc
In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B07C4CDE2@tayexc13.americas.cpqcorp.net>
Message-ID: <Pine.LNX.4.61.0411102313270.29536@netcore.fi>
References: <9C422444DE99BC46B3AD3C6EAFC9711B07C4CDE2@tayexc13.americas.cpqcorp.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

On Wed, 10 Nov 2004, Bound, Jim wrote:
> No I will not contribute until there is a chair and valid IETF WG list
> and charter. [...]

Maybe that is a bit unfair statement, because there can't really be a 
charter or chair until the WG is approved .. at least officially :)

In any case, I've requested and Margaret has approved the creation of 
v6tc@ietf.org mailing list, and it should be set up within one 
business day.

I'm sure Jordi had good intentions here for getting down the path 
quickly, he probably just didn't know how easy it is to set up a 
mailing list at the IETF if there is clear community interest to do it 
:)

I can send an explicit note when I get the ack that the list has been 
set up.

(co-chair hat on)
Can we drop this thread now?  Thanks :)
(hat off)

-- 
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 owner-v6ops@ops.ietf.org  Wed Nov 10 22:49:51 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09964
	for <v6ops-archive@lists.ietf.org>; Wed, 10 Nov 2004 22:49:50 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CS5uk-000Efm-5H
	for v6ops-data@psg.com; Thu, 11 Nov 2004 03:46:26 +0000
Received: from [66.218.79.77] (helo=web80507.mail.yahoo.com)
	by psg.com with smtp (Exim 4.41 (FreeBSD))
	id 1CS5uB-000Eai-A6
	for v6ops@ops.ietf.org; Thu, 11 Nov 2004 03:45:51 +0000
Message-ID: <20041111034550.11403.qmail@web80507.mail.yahoo.com>
Received: from [63.197.18.101] by web80507.mail.yahoo.com via HTTP; Wed, 10 Nov 2004 19:45:50 PST
Date: Wed, 10 Nov 2004 19:45:50 -0800 (PST)
From: Fred Templin <osprey67@yahoo.com>
Subject: Fwd: Re: draft-ietf-ngtrans-isatap-22.txt
To: v6ops@ops.ietf.org, ipv6@ietf.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-717510826-1100144750=:10626"
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-3.7 required=5.0 tests=AWL,BAYES_00,
	FROM_ENDS_IN_NUMS,HTML_FONTCOLOR_BLUE,HTML_MESSAGE,
	HTTP_WITH_EMAIL_IN_URL autolearn=no version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

--0-717510826-1100144750=:10626
Content-Type: text/plain; charset=us-ascii

FYI,
 
After receiving news today from the RFC-Editor of complications with the
publication procedures for this document, I have just sent the forwarded
message below in reply. To those who were genuinely looking forward to
successful publication, I am sorry that I will no longer be able to head up
the effort. To those who were genuinely supportive of the authors' best
interests, my sincere thanks.
 
Fred L. Templin
osprey67@yahoo.com
 

Fred Templin <osprey67@yahoo.com> wrote:
Date: Wed, 10 Nov 2004 19:30:38 -0800 (PST)
From: Fred Templin 
Subject: Re: draft-ietf-ngtrans-isatap-22.txt
To: RFC Editor , tgleeson@cisco.com,
mohitt@microsoft.com, dthaler@microsoft.com
CC: braden@ISI.EDU, smb@research.att.com, zinin@psg.com, osprey67@yahoo.com


IMHO (and speaking only for myself) significant factions in the IETF are clearlydeeply committed to endless gamesmanship with respect to this particulardocument. Up to now my co-authors and I have participated in good faith, butthat faith has been betrayed time and again by bad politics and ill-manneredindividuals. As such (and after many years of strenuous concerted effort aswitnessed by mailing list archives) I no longer have faith that additional energycontributed toward this enterprise could possibly bear fruits. I therefore regretthat I must inform you of my decision to abandon the effort as lead author.To my co-authors, I would like to wish each of you the very best in decidinghow to proceed from here. I will be happy to turn over to you any materialsyou may need to continue the effort should you choose to do so. Please beaware that my former employer (SRI International) is claiming IPR - see:  https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=193Since I am no
 longer associated with SRI (and since I have no legal expertiseas basis for advising you) I recommend working through the contact informationfound on the IPR statement if you should have any questions.Sincerely,Fred L. Templinosprey67@yahoo.com


--0-717510826-1100144750=:10626
Content-Type: text/html; charset=us-ascii

<DIV>FYI,</DIV>
<DIV>&nbsp;</DIV>
<DIV>After receiving news today&nbsp;from the RFC-Editor of complications with the</DIV>
<DIV>publication procedures for this document, I have just sent the forwarded</DIV>
<DIV>message below in reply. To those who were genuinely&nbsp;looking forward to</DIV>
<DIV>successful publication, I am sorry that I will no longer be able to head up</DIV>
<DIV>the effort. To those who&nbsp;were genuinely supportive of the authors'&nbsp;best</DIV>
<DIV>interests, my sincere thanks.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Fred L. Templin</DIV>
<DIV><A href="mailto:osprey67@yahoo.com">osprey67@yahoo.com</A></DIV>
<DIV>&nbsp;<BR><BR><B><I>Fred Templin &lt;osprey67@yahoo.com&gt;</I></B> wrote:</DIV>
<BLOCKQUOTE class=replbq style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">Date: Wed, 10 Nov 2004 19:30:38 -0800 (PST)<BR>From: Fred Templin <OSPREY67@YAHOO.COM><BR>Subject: Re: draft-ietf-ngtrans-isatap-22.txt<BR>To: RFC Editor <RFC-EDITOR@RFC-EDITOR.ORG>, tgleeson@cisco.com,<BR>mohitt@microsoft.com, dthaler@microsoft.com<BR>CC: braden@ISI.EDU, smb@research.att.com, zinin@psg.com, <A href="mailto:osprey67@yahoo.com">osprey67@yahoo.com</A><BR><BR>
<DIV><PRE><TT><FONT face=arial>IMHO (and speaking only for myself) significant factions in the IETF are clearly
deeply committed to endless gamesmanship with respect to this particular
document. Up to now my co-authors and I have participated in good faith, but
that faith has been betrayed time and again by bad politics and ill-mannered
individuals. As such (and after many years of strenuous concerted effort as
witnessed by mailing list archives) I no longer have faith that additional energy</FONT></TT><TT><FONT face=arial>
contributed toward this enterprise could possibly bear fruits. I therefore regret
that I must inform you of my decision to abandon the effort as lead author.

To my co-authors, I would like to wish each of you the very best in deciding
how to proceed from here. I will be happy to turn over to you any materials
you may need to continue the effort should you choose to do so. Please be
aware that my former employer (SRI International) is claiming IPR </FONT></TT><TT><FONT face=arial>- see:

  </FONT><A href="https://datatracker.ietf.org/public/ipr_detail_show.cgi?&amp;ipr_id=193" target=_blank><FONT face=arial color=#003399>https://datatracker.ietf.org/public/ipr_detail_show.cgi?&amp;ipr_id=193</FONT></A>

<FONT face=arial>Since I am no longer associated with SRI (and since I have no legal expertise
as basis for advising you) I recommend working through the contact information
found on the IPR statement if you should have any questions.

Sincerely,

Fred L. Templin
</FONT><A href="http://us.f805.mail.yahoo.com/ym/Compose?To=osprey67@yahoo.com&amp;YY=15684&amp;order=down&amp;sort=date&amp;pos=0&amp;view=a&amp;head=f"><FONT face=arial color=#003399>osprey67@yahoo.com</FONT></A></TT></PRE></DIV></BLOCKQUOTE>
--0-717510826-1100144750=:10626--



From owner-v6ops@ops.ietf.org  Thu Nov 11 07:20:58 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02186
	for <v6ops-archive@lists.ietf.org>; Thu, 11 Nov 2004 07:20:57 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CSDu9-000EYm-Q2
	for v6ops-data@psg.com; Thu, 11 Nov 2004 12:18:21 +0000
Received: from [195.212.29.137] (helo=mtagate4.uk.ibm.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CSDsY-000ELC-8R
	for v6ops@ops.ietf.org; Thu, 11 Nov 2004 12:16:42 +0000
Received: from d06nrmr1307.portsmouth.uk.ibm.com (d06nrmr1307.portsmouth.uk.ibm.com [9.149.38.129])
	by mtagate4.uk.ibm.com (8.12.10/8.12.10) with ESMTP id iABCGfrQ244752;
	Thu, 11 Nov 2004 12:16:41 GMT
Received: from sihl.zurich.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228])
	by d06nrmr1307.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iABCGeOb081210;
	Thu, 11 Nov 2004 12:16:40 GMT
Received: from zurich.ibm.com (sig-9-145-250-204.de.ibm.com [9.145.250.204])
	by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id NAA69496;
	Thu, 11 Nov 2004 13:16:38 +0100
Message-ID: <41935807.3040402@zurich.ibm.com>
Date: Thu, 11 Nov 2004 13:16:07 +0100
From: Brian E Carpenter <brc@zurich.ibm.com>
Organization: IBM
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en, fr, de
MIME-Version: 1.0
To: Fred Templin <osprey67@yahoo.com>
CC: v6ops@ops.ietf.org
Subject: Re: Fwd: Re: draft-ietf-ngtrans-isatap-22.txt
References: <20041111034550.11403.qmail@web80507.mail.yahoo.com>
In-Reply-To: <20041111034550.11403.qmail@web80507.mail.yahoo.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Fred, could you be more explicit about the "complications"?

The IPR disclosure in question reads (in its essence):

>    b) _X_   Royalty-Free, Reasonable and Non-Discriminatory License to
>             All Implementers
>               Check here if this licensing declaration is limited solely
>               to standards-track IETF documents ___

    Brian


Fred Templin wrote:
> FYI,
>  
> After receiving news today from the RFC-Editor of complications with the
> publication procedures for this document, I have just sent the forwarded
> message below in reply. To those who were genuinely looking forward to
> successful publication, I am sorry that I will no longer be able to head up
> the effort. To those who were genuinely supportive of the authors' best
> interests, my sincere thanks.
>  
> Fred L. Templin
> osprey67@yahoo.com
>  
> 
> Fred Templin <osprey67@yahoo.com> wrote:
> Date: Wed, 10 Nov 2004 19:30:38 -0800 (PST)
> From: Fred Templin 
> Subject: Re: draft-ietf-ngtrans-isatap-22.txt
> To: RFC Editor , tgleeson@cisco.com,
> mohitt@microsoft.com, dthaler@microsoft.com
> CC: braden@ISI.EDU, smb@research.att.com, zinin@psg.com, osprey67@yahoo.com
> 
> 
> IMHO (and speaking only for myself) significant factions in the IETF are clearlydeeply committed to endless gamesmanship with respect to this particulardocument. Up to now my co-authors and I have participated in good faith, butthat faith has been betrayed time and again by bad politics and ill-manneredindividuals. As such (and after many years of strenuous concerted effort aswitnessed by mailing list archives) I no longer have faith that additional energycontributed toward this enterprise could possibly bear fruits. I therefore regretthat I must inform you of my decision to abandon the effort as lead author.To my co-authors, I would like to wish each of you the very best in decidinghow to proceed from here. I will be happy to turn over to you any materialsyou may need to continue the effort should you choose to do so. Please beaware that my former employer (SRI International) is claiming IPR - see:  https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=193Since 
I !
>  am no
>  longer associated with SRI (and since I have no legal expertiseas basis for advising you) I recommend working through the contact informationfound on the IPR statement if you should have any questions.Sincerely,Fred L. Templinosprey67@yahoo.com
> 
> 




From owner-v6ops@ops.ietf.org  Thu Nov 11 08:50:26 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10695
	for <v6ops-archive@lists.ietf.org>; Thu, 11 Nov 2004 08:50:25 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CSFJm-000055-7E
	for v6ops-data@psg.com; Thu, 11 Nov 2004 13:48:54 +0000
Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CSFJb-00003i-Cn
	for v6ops@ops.ietf.org; Thu, 11 Nov 2004 13:48:43 +0000
Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131])
	by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id iABDmgGn023501
	for <v6ops@ops.ietf.org>; Thu, 11 Nov 2004 13:48:42 GMT
Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162])
	by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id NAA15139
	for <v6ops@ops.ietf.org>; Thu, 11 Nov 2004 13:48:40 GMT
Received: (from tjc@localhost)
	by login.ecs.soton.ac.uk (8.11.6/8.11.6) id iABDmeE20385
	for v6ops@ops.ietf.org; Thu, 11 Nov 2004 13:48:40 GMT
Date: Thu, 11 Nov 2004 13:48:40 +0000
From: Tim Chown <tjc@ecs.soton.ac.uk>
To: v6ops@ops.ietf.org
Subject: Re: Fwd: Re: draft-ietf-ngtrans-isatap-22.txt
Message-ID: <20041111134840.GR17310@login.ecs.soton.ac.uk>
Mail-Followup-To: v6ops@ops.ietf.org
References: <20041111034550.11403.qmail@web80507.mail.yahoo.com> <41935807.3040402@zurich.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <41935807.3040402@zurich.ibm.com>
User-Agent: Mutt/1.4i
X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information
X-ECS-MailScanner: Found to be clean
X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

On Thu, Nov 11, 2004 at 01:16:07PM +0100, Brian E Carpenter wrote:
> Fred, could you be more explicit about the "complications"?

I would also be interested to hear about this; I had expected that note
to be below your reply.

Tim



From owner-v6ops@ops.ietf.org  Thu Nov 11 10:35:26 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23202
	for <v6ops-archive@lists.ietf.org>; Thu, 11 Nov 2004 10:35:25 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CSGwb-000Ddp-To
	for v6ops-data@psg.com; Thu, 11 Nov 2004 15:33:05 +0000
Received: from [131.228.20.21] (helo=mgw-x1.nokia.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CSGvm-000Dar-S3
	for v6ops@ops.ietf.org; Thu, 11 Nov 2004 15:32:15 +0000
Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159])
	by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iABFWCv20675;
	Thu, 11 Nov 2004 17:32:13 +0200 (EET)
X-Scanned: Thu, 11 Nov 2004 17:31:25 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE
Received: (from root@localhost)
	by esdks004.ntc.nokia.com (8.12.9/8.12.9) id iABFVPoB026664;
	Thu, 11 Nov 2004 17:31:25 +0200
Received: from mgw-int1.ntc.nokia.com (172.21.143.96)
	by esdks004.ntc.nokia.com 00lWeTkI; Thu, 11 Nov 2004 17:31:23 EET
Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82])
	by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iABFVNa04664;
	Thu, 11 Nov 2004 17:31:23 +0200 (EET)
Received: from esebe001.NOE.Nokia.com ([172.21.138.30]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881);
	 Thu, 11 Nov 2004 17:31:22 +0200
Received: from esebe054.NOE.Nokia.com ([172.21.143.44]) by esebe001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881);
	 Thu, 11 Nov 2004 17:31:22 +0200
Received: ESEBE054.noe.nokia.com 172.21.143.44 from 10.241.59.104 10.241.59.104 via HTTP with MS-WebStorage 6.0.6249
Received: from localhost.localdomain by ESEBE054.noe.nokia.com; 11 Nov 2004 17:31:13 +0200
Subject: Re: Fwd: Re: draft-ietf-ngtrans-isatap-22.txt
From: "Soininen Jonne (Nokia-NET/Helsinki)" <jonne.soininen@nokia.com>
To: ext Tim Chown <tjc@ecs.soton.ac.uk>
Cc: v6ops@ops.ietf.org
In-Reply-To: <20041111134840.GR17310@login.ecs.soton.ac.uk>
References: <20041111034550.11403.qmail@web80507.mail.yahoo.com>
	 <41935807.3040402@zurich.ibm.com>
	 <20041111134840.GR17310@login.ecs.soton.ac.uk>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1100187073.4615.24.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.6 
Date: Thu, 11 Nov 2004 17:31:13 +0200
X-OriginalArrivalTime: 11 Nov 2004 15:31:22.0112 (UTC) FILETIME=[7F66D800:01C4C803]
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hello,

I think what Fred is referring to are the comments that some IESG people
gave to the ISATAP specification. There were basically two comments: One
about the clarity of the security considerations section and one
addressing the clarity of the definition of the term site.

I would like to take this opportunity to thank Fred for his support and
contribution to this WG and especially for his work on ISATAP. I hope
the other authors can take the ball on this on this and one of the other
authors would take Fred's position. I am also personally prepared to
help in the last nits - if needed.

Cheers,

Jonne.

On Thu, 2004-11-11 at 15:48, ext Tim Chown wrote:
> On Thu, Nov 11, 2004 at 01:16:07PM +0100, Brian E Carpenter wrote:
> > Fred, could you be more explicit about the "complications"?
> 
> I would also be interested to hear about this; I had expected that note
> to be below your reply.
> 
> Tim
-- 
Jonne Soininen
Nokia

Tel: +358 40 527 46 34
E-mail: jonne.soininen@nokia.com



From owner-v6ops@ops.ietf.org  Thu Nov 11 10:49:30 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24603
	for <v6ops-archive@lists.ietf.org>; Thu, 11 Nov 2004 10:49:29 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CSHBl-000FhD-IZ
	for v6ops-data@psg.com; Thu, 11 Nov 2004 15:48:45 +0000
Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CSHBP-000FeZ-9a
	for v6ops@ops.ietf.org; Thu, 11 Nov 2004 15:48:23 +0000
Received: from esunmail ([129.147.156.34])
	by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id iABFmMui019839
	for <v6ops@ops.ietf.org>; Thu, 11 Nov 2004 08:48:22 -0700 (MST)
Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM
 (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTP id <0I7000ANPUKMKY@edgemail1.Central.Sun.COM> for
 v6ops@ops.ietf.org; Thu, 11 Nov 2004 08:48:22 -0700 (MST)
Received: from [130.129.134.64] by mail.sun.net
 (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I7000LVLUKLOZ@mail.sun.net> for v6ops@ops.ietf.org; Thu,
 11 Nov 2004 08:48:22 -0700 (MST)
Date: Thu, 11 Nov 2004 07:50:02 -0800
From: Alain Durand <Alain.Durand@Sun.COM>
Subject: Re: Fwd: Re: draft-ietf-ngtrans-isatap-22.txt
In-reply-to: <1100187073.4615.24.camel@localhost.localdomain>
To: "Soininen Jonne (Nokia-NET/Helsinki)" <jonne.soininen@nokia.com>
Cc: v6ops@ops.ietf.org
Message-id: <41938A2A.6070505@sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20040906
References: <20041111034550.11403.qmail@web80507.mail.yahoo.com>
 <41935807.3040402@zurich.ibm.com>
 <20041111134840.GR17310@login.ecs.soton.ac.uk>
 <1100187073.4615.24.camel@localhost.localdomain>
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7BIT

Soininen Jonne (Nokia-NET/Helsinki) wrote:
> Hello,
> 
> I think what Fred is referring to are the comments that some IESG people
> gave to the ISATAP specification. There were basically two comments: One
> about the clarity of the security considerations section and one
> addressing the clarity of the definition of the term site.


Jonne,

Could you please clarify what is the exact status of the draft here?
Yesterday, we've heard it was inthe RFC editor queue for Experimental
and that the door was open to, if folks wanted, after experimental 
feedback, clean-up the spec and republish it as PS with AD direct sponsor.

Do the IESG comments you mentionned above are blocking the publication
now as Experiemntal or the potential later re-publication as PS?

	- Alain.



From owner-v6ops@ops.ietf.org  Thu Nov 11 11:02:26 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25874
	for <v6ops-archive@lists.ietf.org>; Thu, 11 Nov 2004 11:02:25 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CSHOB-000Hos-Kn
	for v6ops-data@psg.com; Thu, 11 Nov 2004 16:01:35 +0000
Received: from [131.228.20.21] (helo=mgw-x1.nokia.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CSHO0-000Hn9-N5
	for v6ops@ops.ietf.org; Thu, 11 Nov 2004 16:01:25 +0000
Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120])
	by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iABG1Jv03547;
	Thu, 11 Nov 2004 18:01:22 +0200 (EET)
X-Scanned: Thu, 11 Nov 2004 18:00:29 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE
Received: (from root@localhost)
	by esdks001.ntc.nokia.com (8.12.9/8.12.9) id iABG0T96029427;
	Thu, 11 Nov 2004 18:00:29 +0200
Received: from mgw-int2.ntc.nokia.com (172.21.143.97)
	by esdks001.ntc.nokia.com 005QC2TZ; Thu, 11 Nov 2004 18:00:27 EET
Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77])
	by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iABFwrS19536;
	Thu, 11 Nov 2004 17:58:53 +0200 (EET)
Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881);
	 Thu, 11 Nov 2004 17:58:52 +0200
Received: from esebe054.NOE.Nokia.com ([172.21.143.44]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881);
	 Thu, 11 Nov 2004 17:58:52 +0200
Received: ESEBE054.noe.nokia.com 172.21.143.44 from 10.241.59.104 10.241.59.104 via HTTP with MS-WebStorage 6.0.6249
Received: from localhost.localdomain by ESEBE054.noe.nokia.com; 11 Nov 2004 17:58:43 +0200
Subject: Re: Fwd: Re: draft-ietf-ngtrans-isatap-22.txt
From: "Soininen Jonne (Nokia-NET/Helsinki)" <jonne.soininen@nokia.com>
To: ext Alain Durand <Alain.Durand@Sun.COM>
Cc: v6ops@ops.ietf.org
In-Reply-To: <41938A2A.6070505@sun.com>
References: <20041111034550.11403.qmail@web80507.mail.yahoo.com>
	 <41935807.3040402@zurich.ibm.com>
	 <20041111134840.GR17310@login.ecs.soton.ac.uk>
	 <1100187073.4615.24.camel@localhost.localdomain> <41938A2A.6070505@sun.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1100188722.4615.40.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.6 
Date: Thu, 11 Nov 2004 17:58:43 +0200
X-OriginalArrivalTime: 11 Nov 2004 15:58:52.0104 (UTC) FILETIME=[56DFA480:01C4C807]
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Alain,

yes, maybe this merits a few words about the status of the document:

1) The document has been submitted as an individual submission to the
RFC Editor. IESG has taken a look at it and some (minor) comments were
raised.
2) RFC Editor has asked the authors to address those comments
3) After the comments are addressed the document will be published by
the RFC Editor.

There are _no_ showstoppers in the way and this will be published. In
addition, whether to publish ISATAP later as a standards track document
is in no conflict with the process here.

I hope this clears the situation.

Cheers,

Jonne.
On Thu, 2004-11-11 at 17:50, ext Alain Durand wrote:
> Soininen Jonne (Nokia-NET/Helsinki) wrote:
> > Hello,
> > 
> > I think what Fred is referring to are the comments that some IESG people
> > gave to the ISATAP specification. There were basically two comments: One
> > about the clarity of the security considerations section and one
> > addressing the clarity of the definition of the term site.
> 
> 
> Jonne,
> 
> Could you please clarify what is the exact status of the draft here?
> Yesterday, we've heard it was inthe RFC editor queue for Experimental
> and that the door was open to, if folks wanted, after experimental 
> feedback, clean-up the spec and republish it as PS with AD direct sponsor.
> 
> Do the IESG comments you mentionned above are blocking the publication
> now as Experiemntal or the potential later re-publication as PS?
> 
> 	- Alain.
-- 
Jonne Soininen
Nokia

Tel: +358 40 527 46 34
E-mail: jonne.soininen@nokia.com



From owner-v6ops@ops.ietf.org  Thu Nov 11 11:12:00 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26732
	for <v6ops-archive@lists.ietf.org>; Thu, 11 Nov 2004 11:12:00 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CSHXI-000JO9-M1
	for v6ops-data@psg.com; Thu, 11 Nov 2004 16:11:00 +0000
Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CSHX7-000JNP-Rk
	for v6ops@ops.ietf.org; Thu, 11 Nov 2004 16:10:50 +0000
Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131])
	by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id iABGAmGn028017
	for <v6ops@ops.ietf.org>; Thu, 11 Nov 2004 16:10:48 GMT
Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162])
	by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id QAA27075
	for <v6ops@ops.ietf.org>; Thu, 11 Nov 2004 16:10:45 GMT
Received: (from tjc@localhost)
	by login.ecs.soton.ac.uk (8.11.6/8.11.6) id iABGAj724254
	for v6ops@ops.ietf.org; Thu, 11 Nov 2004 16:10:45 GMT
Date: Thu, 11 Nov 2004 16:10:45 +0000
From: Tim Chown <tjc@ecs.soton.ac.uk>
To: v6ops@ops.ietf.org
Subject: Re: Fwd: Re: draft-ietf-ngtrans-isatap-22.txt
Message-ID: <20041111161045.GT20915@login.ecs.soton.ac.uk>
Mail-Followup-To: v6ops@ops.ietf.org
References: <20041111034550.11403.qmail@web80507.mail.yahoo.com> <41935807.3040402@zurich.ibm.com> <20041111134840.GR17310@login.ecs.soton.ac.uk> <1100187073.4615.24.camel@localhost.localdomain> <41938A2A.6070505@sun.com> <1100188722.4615.40.camel@localhost.localdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1100188722.4615.40.camel@localhost.localdomain>
User-Agent: Mutt/1.4i
X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information
X-ECS-MailScanner: Found to be clean
X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

On Thu, Nov 11, 2004 at 05:58:43PM +0200, Soininen Jonne (Nokia-NET/Helsinki) wrote:
> Alain,
> 
> yes, maybe this merits a few words about the status of the document:
> 
> 1) The document has been submitted as an individual submission to the
> RFC Editor. IESG has taken a look at it and some (minor) comments were
> raised.
> 2) RFC Editor has asked the authors to address those comments
> 3) After the comments are addressed the document will be published by
> the RFC Editor.
> 
> There are _no_ showstoppers in the way and this will be published. In
> addition, whether to publish ISATAP later as a standards track document
> is in no conflict with the process here.
> 
> I hope this clears the situation.

I share Brian/Alain's curiosity/concern, and I don't see how "nits" would
cause Fred to adbandon the work (inside the IETF at least).

I guess if Fred does not want to comment, that is his perogative, but it
seems ISATAP is very close to Experimental publication, which is good!

Tim



From owner-v6ops@ops.ietf.org  Thu Nov 11 11:19:31 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27275
	for <v6ops-archive@lists.ietf.org>; Thu, 11 Nov 2004 11:19:31 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CSHeO-000KFl-6N
	for v6ops-data@psg.com; Thu, 11 Nov 2004 16:18:20 +0000
Received: from [195.212.29.151] (helo=mtagate2.de.ibm.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CSHeC-000KF3-QU
	for v6ops@ops.ietf.org; Thu, 11 Nov 2004 16:18:09 +0000
Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49])
	by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id iABGI2xD175676;
	Thu, 11 Nov 2004 16:18:02 GMT
Received: from sihl.zurich.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228])
	by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iABGI1tQ098506;
	Thu, 11 Nov 2004 17:18:01 +0100
Received: from zurich.ibm.com (sig-9-145-251-42.de.ibm.com [9.145.251.42])
	by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id RAA63588;
	Thu, 11 Nov 2004 17:17:59 +0100
Message-ID: <419390B1.2090502@zurich.ibm.com>
Date: Thu, 11 Nov 2004 17:17:53 +0100
From: Brian E Carpenter <brc@zurich.ibm.com>
Organization: IBM
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en, fr, de
MIME-Version: 1.0
To: Alain Durand <Alain.Durand@Sun.COM>
CC: "Soininen Jonne (Nokia-NET/Helsinki)" <jonne.soininen@nokia.com>,
        v6ops@ops.ietf.org
Subject: Re: Fwd: Re: draft-ietf-ngtrans-isatap-22.txt
References: <20041111034550.11403.qmail@web80507.mail.yahoo.com> <41935807.3040402@zurich.ibm.com> <20041111134840.GR17310@login.ecs.soton.ac.uk> <1100187073.4615.24.camel@localhost.localdomain> <41938A2A.6070505@sun.com>
In-Reply-To: <41938A2A.6070505@sun.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

The tracker says:

 > 2004-09-23	22	[amyk]
 > State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza

so the IESG is out of the loop.

The RFC Editor queue says:

> -------------------------------------------------------------------
> NON-WORKING GROUP INFORMATIONAL/EXPERIMENTAL/BCP (by date received)
> -------------------------------------------------------------------

[>20 older entries deleted]

> 2004/06/08-I  draft-ietf-ngtrans-isatap-22.txt
> ISR           8/23/04
> F. Templin, T. Gleeson, M. Talwar, D. Thaler
> Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)
> Bytes: 28963

Can we see the RFC Editor review comments, please?

    Brian

Alain Durand wrote:
> Soininen Jonne (Nokia-NET/Helsinki) wrote:
> 
>> Hello,
>>
>> I think what Fred is referring to are the comments that some IESG people
>> gave to the ISATAP specification. There were basically two comments: One
>> about the clarity of the security considerations section and one
>> addressing the clarity of the definition of the term site.
> 
> 
> 
> Jonne,
> 
> Could you please clarify what is the exact status of the draft here?
> Yesterday, we've heard it was inthe RFC editor queue for Experimental
> and that the door was open to, if folks wanted, after experimental 
> feedback, clean-up the spec and republish it as PS with AD direct sponsor.
> 
> Do the IESG comments you mentionned above are blocking the publication
> now as Experiemntal or the potential later re-publication as PS?
> 
>     - Alain.
> 



From owner-v6ops@ops.ietf.org  Thu Nov 11 11:25:51 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27807
	for <v6ops-archive@lists.ietf.org>; Thu, 11 Nov 2004 11:25:51 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CSHkx-000L71-FG
	for v6ops-data@psg.com; Thu, 11 Nov 2004 16:25:07 +0000
Received: from [131.228.20.22] (helo=mgw-x2.nokia.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CSHkm-000L2i-Hi
	for v6ops@ops.ietf.org; Thu, 11 Nov 2004 16:24:56 +0000
Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120])
	by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iABGOsF15000;
	Thu, 11 Nov 2004 18:24:54 +0200 (EET)
X-Scanned: Thu, 11 Nov 2004 18:24:30 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE
Received: (from root@localhost)
	by esdks001.ntc.nokia.com (8.12.9/8.12.9) id iABGOUgl032128;
	Thu, 11 Nov 2004 18:24:30 +0200
Received: from mgw-int1.ntc.nokia.com (172.21.143.96)
	by esdks001.ntc.nokia.com 00BgsQWc; Thu, 11 Nov 2004 18:24:28 EET
Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28])
	by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iABGMxa20951;
	Thu, 11 Nov 2004 18:22:59 +0200 (EET)
Received: from esebe017.NOE.Nokia.com ([172.21.138.56]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881);
	 Thu, 11 Nov 2004 18:22:57 +0200
Received: from esebe054.NOE.Nokia.com ([172.21.143.44]) by esebe017.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881);
	 Thu, 11 Nov 2004 18:22:57 +0200
Received: ESEBE054.noe.nokia.com 172.21.143.44 from 10.241.59.104 10.241.59.104 via HTTP with MS-WebStorage 6.0.6249
Received: from localhost.localdomain by ESEBE054.noe.nokia.com; 11 Nov 2004 18:22:48 +0200
Subject: Re: Fwd: Re: draft-ietf-ngtrans-isatap-22.txt
From: "Soininen Jonne (Nokia-NET/Helsinki)" <jonne.soininen@nokia.com>
To: ext Brian E Carpenter <brc@zurich.ibm.com>
Cc: Alain Durand <alain.durand@sun.com>, v6ops@ops.ietf.org
In-Reply-To: <419390B1.2090502@zurich.ibm.com>
References: <20041111034550.11403.qmail@web80507.mail.yahoo.com>
	 <41935807.3040402@zurich.ibm.com>
	 <20041111134840.GR17310@login.ecs.soton.ac.uk>
	 <1100187073.4615.24.camel@localhost.localdomain> <41938A2A.6070505@sun.com>
	 <419390B1.2090502@zurich.ibm.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1100190167.4615.46.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.6 
Date: Thu, 11 Nov 2004 18:22:48 +0200
X-OriginalArrivalTime: 11 Nov 2004 16:22:57.0124 (UTC) FILETIME=[B42C3240:01C4C80A]
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi,

I hope the authors could share the comments with the WG.

Cheers,

Jonne.
On Thu, 2004-11-11 at 18:17, ext Brian E Carpenter wrote:
> The tracker says:
> 
>  > 2004-09-23	22	[amyk]
>  > State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
> 
> so the IESG is out of the loop.
> 
> The RFC Editor queue says:
> 
> > -------------------------------------------------------------------
> > NON-WORKING GROUP INFORMATIONAL/EXPERIMENTAL/BCP (by date received)
> > -------------------------------------------------------------------
> 
> [>20 older entries deleted]
> 
> > 2004/06/08-I  draft-ietf-ngtrans-isatap-22.txt
> > ISR           8/23/04
> > F. Templin, T. Gleeson, M. Talwar, D. Thaler
> > Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)
> > Bytes: 28963
> 
> Can we see the RFC Editor review comments, please?
> 
>     Brian
> 
> Alain Durand wrote:
> > Soininen Jonne (Nokia-NET/Helsinki) wrote:
> > 
> >> Hello,
> >>
> >> I think what Fred is referring to are the comments that some IESG people
> >> gave to the ISATAP specification. There were basically two comments: One
> >> about the clarity of the security considerations section and one
> >> addressing the clarity of the definition of the term site.
> > 
> > 
> > 
> > Jonne,
> > 
> > Could you please clarify what is the exact status of the draft here?
> > Yesterday, we've heard it was inthe RFC editor queue for Experimental
> > and that the door was open to, if folks wanted, after experimental 
> > feedback, clean-up the spec and republish it as PS with AD direct sponsor.
> > 
> > Do the IESG comments you mentionned above are blocking the publication
> > now as Experiemntal or the potential later re-publication as PS?
> > 
> >     - Alain.
> > 
-- 
Jonne Soininen
Nokia

Tel: +358 40 527 46 34
E-mail: jonne.soininen@nokia.com



From owner-v6ops@ops.ietf.org  Thu Nov 11 11:46:32 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29985
	for <v6ops-archive@lists.ietf.org>; Thu, 11 Nov 2004 11:46:31 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CSI45-000NPq-4H
	for v6ops-data@psg.com; Thu, 11 Nov 2004 16:44:53 +0000
Received: from [66.218.79.73] (helo=web80503.mail.yahoo.com)
	by psg.com with smtp (Exim 4.41 (FreeBSD))
	id 1CSI3W-000NN2-Cx
	for v6ops@ops.ietf.org; Thu, 11 Nov 2004 16:44:18 +0000
Message-ID: <20041111164417.56553.qmail@web80503.mail.yahoo.com>
Received: from [63.197.18.101] by web80503.mail.yahoo.com via HTTP; Thu, 11 Nov 2004 08:44:17 PST
Date: Thu, 11 Nov 2004 08:44:17 -0800 (PST)
From: Fred Templin <osprey67@yahoo.com>
Subject: Re: Fwd: Re: draft-ietf-ngtrans-isatap-22.txt
To: "Soininen Jonne \(Nokia-NET/Helsinki\)" <jonne.soininen@nokia.com>,
        ext Brian E Carpenter <brc@zurich.ibm.com>
Cc: Alain Durand <alain.durand@sun.com>, v6ops@ops.ietf.org
In-Reply-To: <1100190167.4615.46.camel@localhost.localdomain>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1523385499-1100191457=:56482"
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-3.8 required=5.0 tests=AWL,BAYES_00,
	FROM_ENDS_IN_NUMS,HTML_MESSAGE autolearn=no version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

--0-1523385499-1100191457=:56482
Content-Type: text/plain; charset=us-ascii

I will be leaving my home in ~15min and will be away from e-mail
access the rest of the day. If anyone wants to see the RFC Editor's
review comments, perhaps contact the RFC Editor. Near as I can tell,
it's not the authors' business to circulate their private correspondences.
 
Fred
osprey67@yahoo.com


"Soininen Jonne (Nokia-NET/Helsinki)" <jonne.soininen@nokia.com> wrote:
Hi,

I hope the authors could share the comments with the WG.

Cheers,

Jonne.
On Thu, 2004-11-11 at 18:17, ext Brian E Carpenter wrote:
> The tracker says:
> 
> > 2004-09-23 22 [amyk]
> > State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
> 
> so the IESG is out of the loop.
> 
> The RFC Editor queue says:
> 
> > -------------------------------------------------------------------
> > NON-WORKING GROUP INFORMATIONAL/EXPERIMENTAL/BCP (by date received)
> > -------------------------------------------------------------------
> 
> [>20 older entries deleted]
> 
> > 2004/06/08-I draft-ietf-ngtrans-isatap-22.txt
> > ISR 8/23/04
> > F. Templin, T. Gleeson, M. Talwar, D. Thaler
> > Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)
> > Bytes: 28963
> 
> Can we see the RFC Editor review comments, please?
> 
> Brian
> 
> Alain Durand wrote:
> > Soininen Jonne (Nokia-NET/Helsinki) wrote:
> > 
> >> Hello,
> >>
> >> I think what Fred is referring to are the comments that some IESG people
> >> gave to the ISATAP specification. There were basically two comments: One
> >> about the clarity of the security considerations section and one
> >> addressing the clarity of the definition of the term site.
> > 
> > 
> > 
> > Jonne,
> > 
> > Could you please clarify what is the exact status of the draft here?
> > Yesterday, we've heard it was inthe RFC editor queue for Experimental
> > and that the door was open to, if folks wanted, after experimental 
> > feedback, clean-up the spec and republish it as PS with AD direct sponsor.
> > 
> > Do the IESG comments you mentionned above are blocking the publication
> > now as Experiemntal or the potential later re-publication as PS?
> > 
> > - Alain.
> > 
-- 
Jonne Soininen
Nokia

Tel: +358 40 527 46 34
E-mail: jonne.soininen@nokia.com


--0-1523385499-1100191457=:56482
Content-Type: text/html; charset=us-ascii

<DIV>I will be leaving my home in ~15min and will be away from e-mail</DIV>
<DIV>access the rest of the day. If anyone wants to&nbsp;see the RFC Editor's</DIV>
<DIV>review comments, perhaps contact the RFC Editor. Near as I can tell,</DIV>
<DIV>it's not the authors' business to circulate their private correspondences.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Fred</DIV>
<DIV><A href="mailto:osprey67@yahoo.com">osprey67@yahoo.com</A></DIV>
<DIV><BR><BR><B><I>"Soininen Jonne (Nokia-NET/Helsinki)" &lt;jonne.soininen@nokia.com&gt;</I></B> wrote:</DIV>
<BLOCKQUOTE class=replbq style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">Hi,<BR><BR>I hope the authors could share the comments with the WG.<BR><BR>Cheers,<BR><BR>Jonne.<BR>On Thu, 2004-11-11 at 18:17, ext Brian E Carpenter wrote:<BR>&gt; The tracker says:<BR>&gt; <BR>&gt; &gt; 2004-09-23 22 [amyk]<BR>&gt; &gt; State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza<BR>&gt; <BR>&gt; so the IESG is out of the loop.<BR>&gt; <BR>&gt; The RFC Editor queue says:<BR>&gt; <BR>&gt; &gt; -------------------------------------------------------------------<BR>&gt; &gt; NON-WORKING GROUP INFORMATIONAL/EXPERIMENTAL/BCP (by date received)<BR>&gt; &gt; -------------------------------------------------------------------<BR>&gt; <BR>&gt; [&gt;20 older entries deleted]<BR>&gt; <BR>&gt; &gt; 2004/06/08-I draft-ietf-ngtrans-isatap-22.txt<BR>&gt; &gt; ISR 8/23/04<BR>&gt; &gt; F. Templin, T. Gleeson, M. Talwar, D. Thaler<BR>&gt; &gt; Intra-Site Automatic
 Tunnel Addressing Protocol (ISATAP)<BR>&gt; &gt; Bytes: 28963<BR>&gt; <BR>&gt; Can we see the RFC Editor review comments, please?<BR>&gt; <BR>&gt; Brian<BR>&gt; <BR>&gt; Alain Durand wrote:<BR>&gt; &gt; Soininen Jonne (Nokia-NET/Helsinki) wrote:<BR>&gt; &gt; <BR>&gt; &gt;&gt; Hello,<BR>&gt; &gt;&gt;<BR>&gt; &gt;&gt; I think what Fred is referring to are the comments that some IESG people<BR>&gt; &gt;&gt; gave to the ISATAP specification. There were basically two comments: One<BR>&gt; &gt;&gt; about the clarity of the security considerations section and one<BR>&gt; &gt;&gt; addressing the clarity of the definition of the term site.<BR>&gt; &gt; <BR>&gt; &gt; <BR>&gt; &gt; <BR>&gt; &gt; Jonne,<BR>&gt; &gt; <BR>&gt; &gt; Could you please clarify what is the exact status of the draft here?<BR>&gt; &gt; Yesterday, we've heard it was inthe RFC editor queue for Experimental<BR>&gt; &gt; and that the door was open to, if folks wanted, after experimental <BR>&gt; &gt; feedback, clean-up the
 spec and republish it as PS with AD direct sponsor.<BR>&gt; &gt; <BR>&gt; &gt; Do the IESG comments you mentionned above are blocking the publication<BR>&gt; &gt; now as Experiemntal or the potential later re-publication as PS?<BR>&gt; &gt; <BR>&gt; &gt; - Alain.<BR>&gt; &gt; <BR>-- <BR>Jonne Soininen<BR>Nokia<BR><BR>Tel: +358 40 527 46 34<BR>E-mail: jonne.soininen@nokia.com<BR><BR></BLOCKQUOTE>
--0-1523385499-1100191457=:56482--



From owner-v6ops@ops.ietf.org  Thu Nov 11 12:20:11 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04398
	for <v6ops-archive@lists.ietf.org>; Thu, 11 Nov 2004 12:20:10 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CSIb9-00028u-Cn
	for v6ops-data@psg.com; Thu, 11 Nov 2004 17:19:03 +0000
Received: from [192.18.98.36] (helo=brmea-mail-4.sun.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CSIax-00028A-VM
	for v6ops@ops.ietf.org; Thu, 11 Nov 2004 17:18:52 +0000
Received: from esunmail ([129.147.156.34])
	by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id iABHIpNH028745
	for <v6ops@ops.ietf.org>; Thu, 11 Nov 2004 10:18:51 -0700 (MST)
Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM
 (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTP id <0I7000FQSYRE7K@edgemail1.Central.Sun.COM> for
 v6ops@ops.ietf.org; Thu, 11 Nov 2004 10:18:51 -0700 (MST)
Received: from [130.129.134.64] by mail.sun.net
 (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I7000LQNYRD15@mail.sun.net> for v6ops@ops.ietf.org; Thu,
 11 Nov 2004 10:18:50 -0700 (MST)
Date: Thu, 11 Nov 2004 09:20:30 -0800
From: Alain Durand <Alain.Durand@Sun.COM>
Subject: Re: Fwd: Re: draft-ietf-ngtrans-isatap-22.txt
In-reply-to: <20041111164417.56553.qmail@web80503.mail.yahoo.com>
To: Fred Templin <osprey67@yahoo.com>
Cc: "Soininen Jonne (Nokia-NET/Helsinki)" <jonne.soininen@nokia.com>,
        ext Brian E Carpenter <brc@zurich.ibm.com>, v6ops@ops.ietf.org
Message-id: <41939F5E.2090806@sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20040906
References: <20041111164417.56553.qmail@web80503.mail.yahoo.com>
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7BIT

Fred,

I certainly understand your frustration, but as you complained publicly,
I would have thought you would have disclosed the object of
the contention so others could help fix it.

	- Alain.

Fred Templin wrote:
> I will be leaving my home in ~15min and will be away from e-mail
> access the rest of the day. If anyone wants to see the RFC Editor's
> review comments, perhaps contact the RFC Editor. Near as I can tell,
> it's not the authors' business to circulate their private correspondences.



From owner-v6ops@ops.ietf.org  Thu Nov 11 13:02:18 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08123
	for <v6ops-archive@lists.ietf.org>; Thu, 11 Nov 2004 13:02:18 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CSJF8-0007R0-8W
	for v6ops-data@psg.com; Thu, 11 Nov 2004 18:00:22 +0000
Received: from [195.212.29.150] (helo=mtagate1.de.ibm.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CSJEx-0007PO-89
	for v6ops@ops.ietf.org; Thu, 11 Nov 2004 18:00:11 +0000
Received: from d12nrmr1707.megacenter.de.ibm.com (d12nrmr1707.megacenter.de.ibm.com [9.149.167.81])
	by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id iABI09EA180676;
	Thu, 11 Nov 2004 18:00:09 GMT
Received: from sihl.zurich.ibm.com (d12av01.megacenter.de.ibm.com [9.149.165.212])
	by d12nrmr1707.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iABI09fi029998;
	Thu, 11 Nov 2004 19:00:09 +0100
Received: from zurich.ibm.com (sig-9-145-130-149.de.ibm.com [9.145.130.149])
	by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id TAA54976;
	Thu, 11 Nov 2004 19:00:07 +0100
Message-ID: <4193A8A5.8030108@zurich.ibm.com>
Date: Thu, 11 Nov 2004 19:00:05 +0100
From: Brian E Carpenter <brc@zurich.ibm.com>
Organization: IBM
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en, fr, de
MIME-Version: 1.0
To: Alain Durand <Alain.Durand@Sun.COM>
CC: Fred Templin <osprey67@yahoo.com>,
        "Soininen Jonne (Nokia-NET/Helsinki)" <jonne.soininen@nokia.com>,
        v6ops@ops.ietf.org
Subject: Re: Fwd: Re: draft-ietf-ngtrans-isatap-22.txt
References: <20041111164417.56553.qmail@web80503.mail.yahoo.com> <41939F5E.2090806@sun.com>
In-Reply-To: <41939F5E.2090806@sun.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Fred is correct that one shouldn't circulate private mail
without permission.

    Brian

Alain Durand wrote:
> Fred,
> 
> I certainly understand your frustration, but as you complained publicly,
> I would have thought you would have disclosed the object of
> the contention so others could help fix it.
> 
>     - Alain.
> 
> Fred Templin wrote:
> 
>> I will be leaving my home in ~15min and will be away from e-mail
>> access the rest of the day. If anyone wants to see the RFC Editor's
>> review comments, perhaps contact the RFC Editor. Near as I can tell,
>> it's not the authors' business to circulate their private 
>> correspondences.
> 
> 



From owner-v6ops@ops.ietf.org  Thu Nov 11 13:04:18 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08309
	for <v6ops-archive@lists.ietf.org>; Thu, 11 Nov 2004 13:04:18 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CSJIR-0007vb-UP
	for v6ops-data@psg.com; Thu, 11 Nov 2004 18:03:47 +0000
Received: from [195.212.29.135] (helo=mtagate2.uk.ibm.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CSJIH-0007t1-1H
	for v6ops@ops.ietf.org; Thu, 11 Nov 2004 18:03:37 +0000
Received: from d06nrmr1307.portsmouth.uk.ibm.com (d06nrmr1307.portsmouth.uk.ibm.com [9.149.38.129])
	by mtagate2.uk.ibm.com (8.12.10/8.12.10) with ESMTP id iABI3SS9229410;
	Thu, 11 Nov 2004 18:03:28 GMT
Received: from sihl.zurich.ibm.com (d06av03.portsmouth.uk.ibm.com [9.149.37.213])
	by d06nrmr1307.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iABI3ROb095962;
	Thu, 11 Nov 2004 18:03:28 GMT
Received: from zurich.ibm.com (sig-9-145-130-149.de.ibm.com [9.145.130.149])
	by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id TAA74868;
	Thu, 11 Nov 2004 19:03:26 +0100
Message-ID: <4193A96D.50600@zurich.ibm.com>
Date: Thu, 11 Nov 2004 19:03:25 +0100
From: Brian E Carpenter <brc@zurich.ibm.com>
Organization: IBM
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en, fr, de
MIME-Version: 1.0
To: RFC Editor <rfc-ed@ISI.EDU>
CC: IPv6 Operations <v6ops@ops.ietf.org>
Subject: Re: draft-ietf-ngtrans-isatap-22.txt
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi,

Various people on the v6ops mailing list are curious to see
the RFC Editor's review comments on draft-ietf-ngtrans-isatap-22.txt,
since some documents need to cite the future RFC.

Thanks
     Brian (in no official capacity)



From owner-v6ops@ops.ietf.org  Thu Nov 11 13:04:40 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08331
	for <v6ops-archive@lists.ietf.org>; Thu, 11 Nov 2004 13:04:40 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CSJIu-00080z-JR
	for v6ops-data@psg.com; Thu, 11 Nov 2004 18:04:16 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CSJIb-0007wv-Gw
	for v6ops@ops.ietf.org; Thu, 11 Nov 2004 18:03:58 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id iABI3ug26150
	for <v6ops@ops.ietf.org>; Thu, 11 Nov 2004 20:03:56 +0200
Date: Thu, 11 Nov 2004 20:03:56 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: v6ops@ops.ietf.org
Subject: Consensus for moving NAT-PT to experimental?
Message-ID: <Pine.LNX.4.61.0411111940140.25704@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

Hi,

(co-chair hat on)

At the meeting, there was almost unanimous consensus for moving NAT-PT 
to experimental.

The approach which seemed to have significant support was splitting 
the document draft-aoun-v6ops-natpt-deprecate-00.txt in two: the one 
describing issues (which would also request the reclassification), and 
one describing different usage (or non-usage) scenarios.

If you believe this is a bad approach, please voice your concerns 
within a week, by 18th November.  Thanks!

(hat off)

-- 
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 owner-v6ops@ops.ietf.org  Thu Nov 11 14:00:53 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12363
	for <v6ops-archive@lists.ietf.org>; Thu, 11 Nov 2004 14:00:53 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CSKAp-000FNl-0v
	for v6ops-data@psg.com; Thu, 11 Nov 2004 18:59:59 +0000
Received: from [193.180.251.47] (helo=penguin.ericsson.se)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CSKAb-000FJK-M5
	for v6ops@ops.ietf.org; Thu, 11 Nov 2004 18:59:46 +0000
Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121])
	by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id iABIxih5022704
	for <v6ops@ops.ietf.org>; Thu, 11 Nov 2004 19:59:44 +0100 (MET)
Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211);
	 Thu, 11 Nov 2004 19:59:44 +0100
Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id WHLPYY01; Thu, 11 Nov 2004 19:59:44 +0100
Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <VJQGNX5R>; Thu, 11 Nov 2004 19:59:44 +0100
Message-ID: <C26BB8276599A44B85D52F9CE41035E1050B9850@esealnt944.al.sw.ericsson.se>
X-Sybari-Trust: 0f91a41d bfd556f1 1ab6656b 00000139
From: "Karen E. Nielsen (AH/LMD)" <karen.e.nielsen@ericsson.com>
To: "'Soininen Jonne (Nokia-NET/Helsinki)'" <jonne.soininen@nokia.com>
Cc: v6ops@ops.ietf.org
Subject: RE: Fwd: Re: draft-ietf-ngtrans-isatap-22.txt
Date: Thu, 11 Nov 2004 19:59:39 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
X-OriginalArrivalTime: 11 Nov 2004 18:59:44.0606 (UTC) FILETIME=[9B7807E0:01C4C820]
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

If useful, I would certainly also be happy to 
help out here.

Karen

> -----Original Message-----
> From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On
> Behalf Of Soininen Jonne (Nokia-NET/Helsinki)
> Sent: Thursday, November 11, 2004 4:31 PM
> To: ext Tim Chown
> Cc: v6ops@ops.ietf.org
> Subject: Re: Fwd: Re: draft-ietf-ngtrans-isatap-22.txt
> 
> 
> Hello,
> 
> I think what Fred is referring to are the comments that some 
> IESG people
> gave to the ISATAP specification. There were basically two 
> comments: One
> about the clarity of the security considerations section and one
> addressing the clarity of the definition of the term site.
> 
> I would like to take this opportunity to thank Fred for his 
> support and
> contribution to this WG and especially for his work on ISATAP. I hope
> the other authors can take the ball on this on this and one 
> of the other
> authors would take Fred's position. I am also personally prepared to
> help in the last nits - if needed.
> 
> Cheers,
> 
> Jonne.
> 
> On Thu, 2004-11-11 at 15:48, ext Tim Chown wrote:
> > On Thu, Nov 11, 2004 at 01:16:07PM +0100, Brian E Carpenter wrote:
> > > Fred, could you be more explicit about the "complications"?
> > 
> > I would also be interested to hear about this; I had 
> expected that note
> > to be below your reply.
> > 
> > Tim
> -- 
> Jonne Soininen
> Nokia
> 
> Tel: +358 40 527 46 34
> E-mail: jonne.soininen@nokia.com
> 



From owner-v6ops@ops.ietf.org  Thu Nov 11 14:51:59 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17212
	for <v6ops-archive@lists.ietf.org>; Thu, 11 Nov 2004 14:51:59 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CSKxc-000MNI-3o
	for v6ops-data@psg.com; Thu, 11 Nov 2004 19:50:24 +0000
Received: from [62.189.30.132] (helo=paddock.ermy.net)
	by psg.com with smtp (Exim 4.41 (FreeBSD))
	id 1CSKxA-000MG9-FH
	for v6ops@ops.ietf.org; Thu, 11 Nov 2004 19:49:56 +0000
Received: (qmail 25374 invoked by uid 500); 11 Nov 2004 19:47:04 -0000
Date: Thu, 11 Nov 2004 19:47:04 +0000
From: Mark Thompson <mkt@ecs.soton.ac.uk>
To: v6ops@ops.ietf.org
Subject: Renumbering 'think about' draft
Message-ID: <20041111194704.GB19922@nahn.ecs.soton.ac.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4i
X-PGP-KeyID: B01CB416
X-PGP-Fingerprint: 36C9 7B51 2A72 B0ED 1AFF  907F B51A AB3D B01C B416
X-Request-PGP: http://www.ecs.soton.ac.uk/~mkt/pubkey.asc
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

Due to the (healthy) discussion yesterday, my presentation suffered
the guillotine. What I would like to do here is pretty much the same
as the presentation would have done, that is to post a gentle 'nudge'
that the draft exists: "Things to think about when Renumbering an IPv6
network" [1]

I had some slides prepared for the meeting that are posted online [2].

The draft is interim output from on-going activity with partners from
the 6NET project, soliciting input from this community.

It isn't meant to be a complete documentation of issues regarding
network renumbering with IPv6. Rather, it is a scoping text that
serves to assist reserachers at Southampton and WWU Muenster define
experiments to analyse different elements of renumbering.

One point of note is that we are not explicitly trying to validate or
build on the work of Baker, Droms and Lear directly, although as we
gain operational experience using the procedure in
draft-ietf-v6ops-renumbering-procedure, we will document our findings
and feed-through to that work.

In the draft, we begin to detail "triggers", typical actions that
result in the need for a renumbering event, and thus define the
scenarios for renumbering; state some "requirements" - potential
specific goals or requirements for sites or users undergoing an IPv6
renumber event;  spot "ipv6 enablers", features of IPv6 or IP-related
technologies not previously (or widely) available for IPv4, that
assist in renumbering; "factors" affecting renumbering tools (or
further protocols) and include a "call to arms" that is actually an
overview of the key questions driving our work.

It's a personal draft at this stage, not because we don't "have a
home" but because of the  timing of when the work was started. It
isn't entirely clear where this work belongs in light of yesterday's
disucssion - but that's something we will look at in the coming weeks

We would be - as I'm sure the authors of the other draft would also -
be very happy to hear from anyone that has undertaken a significant
renumbering exercise, whether using
draft-ietf-v6ops-renumbering-procedure not.

Our intent is to submit a -01 revision for IETF62 where Tim or I would
like to demonstrate progress on the renumbering challenges.


Mark/


[1]http://www.ietf.org/internet-drafts/draft-chown-v6ops-renumber-thinkabout-00.txt

[2]http://ego.6pack.org/i-d/ietf61-v6ops-mkt.pdf


--
Mark Thompson, Electronics and Computer Science
University of Southampton, UK

::1/128 - no place like home; ::/0 - no place at all



From owner-v6ops@ops.ietf.org  Thu Nov 11 15:53:32 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26258
	for <v6ops-archive@lists.ietf.org>; Thu, 11 Nov 2004 15:53:32 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CSLvH-0004uG-QR
	for v6ops-data@psg.com; Thu, 11 Nov 2004 20:52:03 +0000
Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CSLuS-0004nq-Vs
	for v6ops@ops.ietf.org; Thu, 11 Nov 2004 20:51:13 +0000
Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131])
	by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id iABKouGn005397;
	Thu, 11 Nov 2004 20:50:56 GMT
Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162])
	by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id UAA10603;
	Thu, 11 Nov 2004 20:50:55 GMT
Received: (from tjc@localhost)
	by login.ecs.soton.ac.uk (8.11.6/8.11.6) id iABKotr30570;
	Thu, 11 Nov 2004 20:50:55 GMT
Date: Thu, 11 Nov 2004 20:50:55 +0000
From: Tim Chown <tjc@ecs.soton.ac.uk>
To: Pekka Savola <pekkas@netcore.fi>
Cc: "Bound, Jim" <jim.bound@hp.com>, jordi.palet@consulintel.es,
        v6ops@ops.ietf.org, david.kessens@nokia.com, bwijnen@lucent.com,
        narten@us.ibm.com, margaret@thingmagic.com
Subject: Re: Approval for new WG v6tc
Message-ID: <20041111205055.GG30183@login.ecs.soton.ac.uk>
Mail-Followup-To: Pekka Savola <pekkas@netcore.fi>,
	"Bound, Jim" <jim.bound@hp.com>, jordi.palet@consulintel.es,
	v6ops@ops.ietf.org, david.kessens@nokia.com, bwijnen@lucent.com,
	narten@us.ibm.com, margaret@thingmagic.com
References: <9C422444DE99BC46B3AD3C6EAFC9711B07C4CDE2@tayexc13.americas.cpqcorp.net> <Pine.LNX.4.61.0411102313270.29536@netcore.fi>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.61.0411102313270.29536@netcore.fi>
User-Agent: Mutt/1.4i
X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information
X-ECS-MailScanner: Found to be clean
X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

On Wed, Nov 10, 2004 at 11:17:38PM +0200, Pekka Savola wrote:
> 
> In any case, I've requested and Margaret has approved the creation of 
> v6tc@ietf.org mailing list, and it should be set up within one 
> business day.

... which is today :)
 
Margaret said that it could be possible to get the v6tc proposal into the
next IESG(?) voice call next week.   Is this still possible?  Margaret
implied if we missed that it could be "a few weeks".

Or are we waiting for list objections?

Tim



From owner-v6ops@ops.ietf.org  Thu Nov 11 17:34:44 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07127
	for <v6ops-archive@lists.ietf.org>; Thu, 11 Nov 2004 17:34:44 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CSNUr-000IOd-Uv
	for v6ops-data@psg.com; Thu, 11 Nov 2004 22:32:53 +0000
Received: from [213.172.48.142] (helo=consulintel.es)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CSNUg-000IM0-6K
	for v6ops@ops.ietf.org; Thu, 11 Nov 2004 22:32:42 +0000
Received: from [130.129.67.14] ([130.129.67.14])
	by consulintel.es (consulintel.es [127.0.0.1])
	(MDaemon.PRO.v7.2.0.R)
	with ESMTP id md50000577419.msg
	for <v6ops@ops.ietf.org>; Thu, 11 Nov 2004 23:38:18 +0100
User-Agent: Microsoft-Entourage/10.1.4.030702.0
Date: Thu, 11 Nov 2004 17:32:31 -0500
Subject: Re: Approval for new WG v6tc
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: <v6ops@ops.ietf.org>
Message-ID: <BDB952AF.4F96C%jordi.palet@consulintel.es>
In-Reply-To: <20041111205055.GG30183@login.ecs.soton.ac.uk>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Spam-Processed: consulintel.es, Thu, 11 Nov 2004 23:38:18 +0100
	(not processed: message from valid local sender)
X-MDRemoteIP: 130.129.67.14
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ops.ietf.org
Reply-To: jordi.palet@consulintel.es
X-MDAV-Processed: consulintel.es, Thu, 11 Nov 2004 23:38:20 +0100
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Yes, seems to be today !

You will not believe it, but just wait for 5 minutes ;-)


> De: Tim Chown <tjc@ecs.soton.ac.uk>
> Responder a: owner-v6ops@ops.ietf.org
> Fecha: Thu, 11 Nov 2004 20:50:55 +0000
> Para: Pekka Savola <pekkas@netcore.fi>
> CC: "Bound, Jim" <jim.bound@hp.com>, jordi.palet@consulintel.es,
> v6ops@ops.ietf.org, david.kessens@nokia.com, bwijnen@lucent.com,
> narten@us.ibm.com, margaret@thingmagic.com
> Asunto: Re: Approval for new WG v6tc
> 
> On Wed, Nov 10, 2004 at 11:17:38PM +0200, Pekka Savola wrote:
>> 
>> In any case, I've requested and Margaret has approved the creation of
>> v6tc@ietf.org mailing list, and it should be set up within one
>> business day.
> 
> ... which is today :)
> 
> Margaret said that it could be possible to get the v6tc proposal into the
> next IESG(?) voice call next week.   Is this still possible?  Margaret
> implied if we missed that it could be "a few weeks".
> 
> Or are we waiting for list objections?
> 
> Tim
> 
> 



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






From owner-v6ops@ops.ietf.org  Thu Nov 11 17:38:48 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07572
	for <v6ops-archive@lists.ietf.org>; Thu, 11 Nov 2004 17:38:48 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CSNa6-000J5B-H2
	for v6ops-data@psg.com; Thu, 11 Nov 2004 22:38:18 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
 	by psg.com with esmtp (Exim 4.41 (FreeBSD))
 	id 1CSNQi-000HnJ-HE
 	for v6ops@ops.ietf.org; Thu, 11 Nov 2004 22:28:37 +0000
Received: from localhost (pekkas@localhost)
 	by netcore.fi (8.11.6/8.11.6) with ESMTP id iABMSZe32713
 	for <v6ops@ops.ietf.org>; Fri, 12 Nov 2004 00:28:35 +0200
Date: Fri, 12 Nov 2004 00:28:35 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: v6ops@ops.ietf.org
Subject: v6tc@ietf.org set up
Message-ID: <Pine.LNX.4.61.0411120026180.32562@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham
 	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

Hi,

v6tc@ietf.org list has been set up.  The existing subscriptions on the
list Jordi set up have been transfered (the acknowledgements should
have been sent).

Subscribe if interested at:

https://www1.ietf.org/mailman/listinfo/v6tc

-- 
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 owner-v6ops@ops.ietf.org  Thu Nov 11 17:44:37 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08137
	for <v6ops-archive@lists.ietf.org>; Thu, 11 Nov 2004 17:44:37 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CSNfc-000K3d-9W
	for v6ops-data@psg.com; Thu, 11 Nov 2004 22:44:00 +0000
Received: from [213.172.48.142] (helo=consulintel.es)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CSNfJ-000K0B-BB
	for v6ops@ops.ietf.org; Thu, 11 Nov 2004 22:43:41 +0000
Received: from [130.129.67.14] ([130.129.67.14])
	by consulintel.es (consulintel.es [127.0.0.1])
	(MDaemon.PRO.v7.2.0.R)
	with ESMTP id md50000577427.msg
	for <v6ops@ops.ietf.org>; Thu, 11 Nov 2004 23:49:18 +0100
User-Agent: Microsoft-Entourage/10.1.4.030702.0
Date: Thu, 11 Nov 2004 17:42:53 -0500
Subject: Re: v6tc@ietf.org set up
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: <v6ops@ops.ietf.org>
Message-ID: <BDB9551D.4F97E%jordi.palet@consulintel.es>
In-Reply-To: <Pine.LNX.4.61.0411120026180.32562@netcore.fi>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Spam-Processed: consulintel.es, Thu, 11 Nov 2004 23:49:18 +0100
	(not processed: message from valid local sender)
X-MDRemoteIP: 130.129.67.14
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ops.ietf.org
Reply-To: jordi.palet@consulintel.es
X-MDAV-Processed: consulintel.es, Thu, 11 Nov 2004 23:49:20 +0100
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Pekka,

At least I've received it, so should be ok also for the rest.

Regards,
Jordi


> De: Pekka Savola <pekkas@netcore.fi>
> Responder a: owner-v6ops@ops.ietf.org
> Fecha: Fri, 12 Nov 2004 00:28:35 +0200 (EET)
> Para: v6ops@ops.ietf.org
> Asunto: v6tc@ietf.org set up
> 
> Hi,
> 
> v6tc@ietf.org list has been set up.  The existing subscriptions on the
> list Jordi set up have been transfered (the acknowledgements should
> have been sent).
> 
> Subscribe if interested at:
> 
> https://www1.ietf.org/mailman/listinfo/v6tc
> 
> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> 
> 



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






From owner-v6ops@ops.ietf.org  Fri Nov 12 08:27:35 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00287
	for <v6ops-archive@lists.ietf.org>; Fri, 12 Nov 2004 08:27:34 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CSbOw-000GXf-Nv
	for v6ops-data@psg.com; Fri, 12 Nov 2004 13:23:42 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CSbOl-000GW8-Q5
	for v6ops@ops.ietf.org; Fri, 12 Nov 2004 13:23:32 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id iACDNUl19300
	for <v6ops@ops.ietf.org>; Fri, 12 Nov 2004 15:23:30 +0200
Date: Fri, 12 Nov 2004 15:23:30 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: v6ops@ops.ietf.org
Subject: Consensus: re-charter v6ops with narrower focus?
Message-ID: <Pine.LNX.4.61.0411121514400.19151@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

Hi,

(co-chair hat on)

At the meeting, there was very clear rough consensus to narrow down 
the focus of v6ops, to (in principle) exclude protocol work from the 
charter.  A basis for discussion was:

http://www.netcore.fi/pekkas/ietf/61/v6ops-dow-diff.html

If you believe this is a bad approach, please raise your concerns 
within a week, by November 19th.

I will open the discussion of the new charter in a separate thread, so 
if you agree in principle but have some minor comments on the proposed 
charter, let's take them to a separate thread.

(hat off)

-- 
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 owner-v6ops@ops.ietf.org  Fri Nov 12 08:47:41 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02209
	for <v6ops-archive@lists.ietf.org>; Fri, 12 Nov 2004 08:47:40 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CSbkr-000J3y-4n
	for v6ops-data@psg.com; Fri, 12 Nov 2004 13:46:21 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CSbkf-000IzU-Lb
	for v6ops@ops.ietf.org; Fri, 12 Nov 2004 13:46:10 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id iACDk8p19795
	for <v6ops@ops.ietf.org>; Fri, 12 Nov 2004 15:46:08 +0200
Date: Fri, 12 Nov 2004 15:46:08 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: v6ops@ops.ietf.org
Subject: proposed new v6ops charter
Message-ID: <Pine.LNX.4.61.0411121536190.19151@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

Hi,

(co-chair hat on)

Below is the proposed draft charter for v6ops (I didn't renumber the 
sections at this point) to narrow down the focus.

This is roughly the same as presented at the meeting, with a couple of 
comments/corrections:

  - clarify what "v6-in-v4 using IPsec" meant
  - shift the milestone dates forward a little bit
  - not change the statement on "all protocol work is outside of 
scope": justification being that it may make sense to give out clearly 
"the high-order bit" of what v6ops is (in principle) NOT doing 
(without rechartering)
  - not put back the applications section, as that seems to been done 
elsewhere, and the expertise is elsewhere.  This could be done as part 
of ops work as well.

The charter proposal is below, and at the following URLs.

http://netcore.fi/pekkas/ietf/temp/v6ops-dow.txt
http://netcore.fi/pekkas/ietf/temp/v6ops-dow.html (the diff)

Comments?  Suggestions?  Please try to send them within a week or so.

(hat off)
.................

[[ the most important changes:

- remove item 3 on application development and v4 dependencies
(already done)
- remove standardization of mechanisms from item 6
- remove responsibility of existing basic v6 transition mechanisms
- add new milestones and documents

existing issues still:
  - "operational/security issue" is still a blurry concept
  - should _someone_ be responsible for the protocols? [this is not
    commonplace at IETF, though]
  - the scenarios docs are still there, but they do not trigger any
    protocol work
]]

Description of Working Group:

The global deployment of IPv6 is underway, creating an IPv4/IPv6
Internet consisting of IPv4-only, IPv6-only and IPv4/IPv6 networks and
nodes.  This deployment must be properly handled to avoid the division
of the Internet into separate IPv4 and IPv6 networks while ensuring
global addressing and connectivity for all IPv4 and IPv6 nodes.

The IPv6 Operations Working Group (v6ops) develops guidelines for the
operation of a shared IPv4/IPv6 Internet and provides guidance for
network operators on how to deploy IPv6 into existing IPv4-only
networks, as well as into new network installations.

The v6ops working group will:

1. Solicit input from network operators and users to identify
   operational or security issues with the IPv4/IPv6 Internet, and
   determine solutions or workarounds to those issues.  This includes
   identifying standards work that is needed in other IETF WGs or
   areas and working with those groups/areas to begin appropriate
   work.  These issues will be documented in Informational or BCP
   RFCs, or in Internet-Drafts.

   For example, important pieces of the Internet infrastructure
   such as DNS, SMTP and SIP have specific operational issues when
   they operate in a shared IPv4/IPv6 network. The v6ops WG will
   cooperate with the relevant areas and WGs to document those
   issues, and find protocol or operational solutions to those
   problems.

2. Provide feedback to the IPv6 WG regarding portions of the IPv6
   specifications that cause, or are likely to cause, operational
   or security concerns, and work with the IPv6 WG to resolve
   those concerns.  This feedback will be published in
   Internet-Drafts or RFCs.

4. Publish Informational or BCP RFCs that identify potential security
   risks in the operation of shared IPv4/IPv6 networks, and document
   operational practices to eliminate or mitigate those risks.  This
   work will be done in cooperation with the Security area and other
   relevant areas or working groups.

5. Publish Informational or BCP RFCs that identify and analyze solutions
   for deploying IPv6 within common network environments, such as
   ISP Networks (including Core, HFC/Cable, DSL & Dial-up networks),
   Enterprise Networks, Unmanaged Networks (Home/Small Office), and
   Cellular Networks.

   These documents should serve as useful guides to network
   operators and users on how to deploy IPv6 within their existing
   IPv4 networks, as well as in new network installations.

6. Identify open operational or security issues with the deployment
   scenarios documented in (5) and fully document those open
   issues in Internet-Drafts or Informational RFCs.

IPv6 operational and deployment issues with specific protocols or
technologies (such as Applications, Transport Protocols, Routing
Protocols, DNS or Sub-IP Protocols) are the primary responsibility of
the groups or areas responsible for those protocols or technologies.
However, the v6ops group will provide input to those areas/groups, as
needed, and cooperate with those areas/groups in developing and
reviewing solutions to IPv6 operational and deployment problems.

Specifying any protocols or transition mechanisms is out of scope of the WG.

Goals and Milestones:

  Nov 04
 		Adopt document describing how to use IPsec with draft-ietf-v6ops-mech-v2 as WG item
 		Adopt document describing issues with NAT-PT as WG item
  Dec 04
 		Adopt IPv6 Security Overview as WG item
 		Adopt IPv6 deployment using VLANs as WG item

  Jan 05
                 Adopt ISP IPv6 Deployment Scenarios in Broadband Access Networks as WG item
 		Adopt IPv6 Network Architecture Protection as WG item

  Feb 05
                 Submit IPv6-in-IPv4 Tunneling using IPsec to IESG for Info
 		Submit IPv6 deployment using VLANs as WG item

  Mar 05
                 Submit IPv6 Security Overview to IESG for Info
 		Submit document describing issues with NAT-PT to IESG for Info
  		Submit Enterprise Deployment Analysiss to IESG for Info

  Apr 05		Submit IPv6 Network Architecture Protection to IESG for Info

  May 05		Submit ISP IPv6 Deployment Scenarios in Broadband Access Networks to IESG for Info



From owner-v6ops@ops.ietf.org  Fri Nov 12 10:15:04 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11004
	for <v6ops-archive@lists.ietf.org>; Fri, 12 Nov 2004 10:15:03 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CSd6C-0003yI-OX
	for v6ops-data@psg.com; Fri, 12 Nov 2004 15:12:28 +0000
Received: from [63.240.218.73] (helo=s-utl01-dcpop.stsn.com)
	by psg.com with smtp (Exim 4.41 (FreeBSD))
	id 1CSd62-0003xF-0r
	for v6ops@ops.ietf.org; Fri, 12 Nov 2004 15:12:18 +0000
Received: from dcpop.smtp.stsn.com ([127.0.0.1])
 by s-utl01-dcpop.stsn.com (SAVSMTP 3.1.0.29) with SMTP id M2004111210121332082
 for <v6ops@ops.ietf.org>; Fri, 12 Nov 2004 10:12:13 -0500
Received: from [10.67.87.92] ([10.67.87.92]) by dcpop.smtp.stsn.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Fri, 12 Nov 2004 10:12:13 -0500
Mime-Version: 1.0
X-Sender: margaret@mail.thingmagic.com (Unverified)
Message-Id: <p06020401bdba81151dce@[10.67.87.92]>
In-Reply-To: <20041111205055.GG30183@login.ecs.soton.ac.uk>
References: 
 <9C422444DE99BC46B3AD3C6EAFC9711B07C4CDE2@tayexc13.americas.cpqcorp.net>
 <Pine.LNX.4.61.0411102313270.29536@netcore.fi>
 <20041111205055.GG30183@login.ecs.soton.ac.uk>
Date: Fri, 12 Nov 2004 10:08:45 -0500
To: Tim Chown <tjc@ecs.soton.ac.uk>, Pekka Savola <pekkas@netcore.fi>
From: Margaret Wasserman <margaret@thingmagic.com>
Subject: Re: Approval for new WG v6tc
Cc: "Bound, Jim" <jim.bound@hp.com>, jordi.palet@consulintel.es,
        v6ops@ops.ietf.org, david.kessens@nokia.com, bwijnen@lucent.com,
        narten@us.ibm.com
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-OriginalArrivalTime: 12 Nov 2004 15:12:13.0195 (UTC) FILETIME=[FD01C5B0:01C4C8C9]
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk


I (think that I) indicated that it was unlikely that we could get 
this proposal onto the next IESG telechat (18-Nov), as the agend 
cut-off was yesterday (Thursday, 11-Nov).  I do hope that we can move 
forward quickly on this.

As I mentioned in the meeting, though, I have a few questions on the 
milestones and I will probably have a few other comments on the 
charter.  We also have to figure out who will chair the WG, so I can 
work out the charter details with the chair(s).

My suggestion is that folks continue technical discussion/work on the 
v6tc@ietf.org new mailing list as soon as it is available while the 
ADs/Chairs work out the charter paperwork in parallel.  It seems to 
be a common mistake for IETF technical efforts to rathole on charter 
details, and I hope we can avoid that with this group.

Margaret

At 8:50 PM +0000 11/11/04, Tim Chown wrote:
>On Wed, Nov 10, 2004 at 11:17:38PM +0200, Pekka Savola wrote:
>>
>>  In any case, I've requested and Margaret has approved the creation of
>>  v6tc@ietf.org mailing list, and it should be set up within one
>>  business day.
>
>... which is today :)
>
>Margaret said that it could be possible to get the v6tc proposal into the
>next IESG(?) voice call next week.   Is this still possible?  Margaret
>implied if we missed that it could be "a few weeks".
>
>Or are we waiting for list objections?
>
>Tim




From owner-v6ops@ops.ietf.org  Fri Nov 12 10:34:23 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12991
	for <v6ops-archive@lists.ietf.org>; Fri, 12 Nov 2004 10:34:22 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CSdPo-0006fw-0Y
	for v6ops-data@psg.com; Fri, 12 Nov 2004 15:32:44 +0000
Received: from [213.172.48.142] (helo=consulintel.es)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CSdPc-0006fD-Fi
	for v6ops@ops.ietf.org; Fri, 12 Nov 2004 15:32:33 +0000
Received: from [130.129.135.232] ([130.129.135.232])
	by consulintel.es (consulintel.es [127.0.0.1])
	(MDaemon.PRO.v7.2.0.R)
	with ESMTP id md50000579537.msg
	for <v6ops@ops.ietf.org>; Fri, 12 Nov 2004 16:14:32 +0100
User-Agent: Microsoft-Entourage/10.1.4.030702.0
Date: Fri, 12 Nov 2004 10:06:42 -0500
Subject: Re: proposed new v6ops charter
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: <v6ops@ops.ietf.org>
Message-ID: <BDBA3BB2.4FB62%jordi.palet@consulintel.es>
In-Reply-To: <Pine.LNX.4.61.0411121536190.19151@netcore.fi>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Spam-Processed: consulintel.es, Fri, 12 Nov 2004 16:14:32 +0100
	(not processed: message from valid local sender)
X-MDRemoteIP: 130.129.135.232
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ops.ietf.org
Reply-To: jordi.palet@consulintel.es
X-MDAV-Processed: consulintel.es, Fri, 12 Nov 2004 16:38:02 +0100
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Pekka, all,

Thanks a lot for the openness in making this changes in the list. I think
this is a very important sign of moving into a good direction.

Now, get back to the work ;-)

I mostly agree with your proposed changes, but I've some concerns on number
6. I think it should stay as we have it now, because it already says that
first we will try to do that work (if required), in the most appropriate WG,
and only will be done in v6ops if there is not another option on that
direction.

Also not sure if 3 and 7 should be removed, even if the work is already
done. May be to state that this has been already accomplished ? It seems to
me that removing it is like "canceling" (or out-chartering) the work already
done, which obviously is not what we want to do, right ? Note that I'm not
opposing to this change, just will like to make sure that is the right way
to proceed.

Finally, if we accept as a WG item (which I agree), the IPv6 NAP, then we
should be fair and accept also, at least, the IPv6 Distributed Security
problem statement and requirements documents.

Regards,
Jordi


> De: Pekka Savola <pekkas@netcore.fi>
> Responder a: owner-v6ops@ops.ietf.org
> Fecha: Fri, 12 Nov 2004 15:46:08 +0200 (EET)
> Para: v6ops@ops.ietf.org
> Asunto: proposed new v6ops charter
> 
> Hi,
> 
> (co-chair hat on)
> 
> Below is the proposed draft charter for v6ops (I didn't renumber the
> sections at this point) to narrow down the focus.
> 
> This is roughly the same as presented at the meeting, with a couple of
> comments/corrections:
> 
> - clarify what "v6-in-v4 using IPsec" meant
> - shift the milestone dates forward a little bit
> - not change the statement on "all protocol work is outside of
> scope": justification being that it may make sense to give out clearly
> "the high-order bit" of what v6ops is (in principle) NOT doing
> (without rechartering)
> - not put back the applications section, as that seems to been done
> elsewhere, and the expertise is elsewhere.  This could be done as part
> of ops work as well.
> 
> The charter proposal is below, and at the following URLs.
> 
> http://netcore.fi/pekkas/ietf/temp/v6ops-dow.txt
> http://netcore.fi/pekkas/ietf/temp/v6ops-dow.html (the diff)
> 
> Comments?  Suggestions?  Please try to send them within a week or so.
> 
> (hat off)
> .................
> 
> [[ the most important changes:
> 
> - remove item 3 on application development and v4 dependencies
> (already done)
> - remove standardization of mechanisms from item 6
> - remove responsibility of existing basic v6 transition mechanisms
> - add new milestones and documents
> 
> existing issues still:
> - "operational/security issue" is still a blurry concept
> - should _someone_ be responsible for the protocols? [this is not
>   commonplace at IETF, though]
> - the scenarios docs are still there, but they do not trigger any
>   protocol work
> ]]
> 
> Description of Working Group:
> 
> The global deployment of IPv6 is underway, creating an IPv4/IPv6
> Internet consisting of IPv4-only, IPv6-only and IPv4/IPv6 networks and
> nodes.  This deployment must be properly handled to avoid the division
> of the Internet into separate IPv4 and IPv6 networks while ensuring
> global addressing and connectivity for all IPv4 and IPv6 nodes.
> 
> The IPv6 Operations Working Group (v6ops) develops guidelines for the
> operation of a shared IPv4/IPv6 Internet and provides guidance for
> network operators on how to deploy IPv6 into existing IPv4-only
> networks, as well as into new network installations.
> 
> The v6ops working group will:
> 
> 1. Solicit input from network operators and users to identify
>  operational or security issues with the IPv4/IPv6 Internet, and
>  determine solutions or workarounds to those issues.  This includes
>  identifying standards work that is needed in other IETF WGs or
>  areas and working with those groups/areas to begin appropriate
>  work.  These issues will be documented in Informational or BCP
>  RFCs, or in Internet-Drafts.
> 
>  For example, important pieces of the Internet infrastructure
>  such as DNS, SMTP and SIP have specific operational issues when
>  they operate in a shared IPv4/IPv6 network. The v6ops WG will
>  cooperate with the relevant areas and WGs to document those
>  issues, and find protocol or operational solutions to those
>  problems.
> 
> 2. Provide feedback to the IPv6 WG regarding portions of the IPv6
>  specifications that cause, or are likely to cause, operational
>  or security concerns, and work with the IPv6 WG to resolve
>  those concerns.  This feedback will be published in
>  Internet-Drafts or RFCs.
> 
> 4. Publish Informational or BCP RFCs that identify potential security
>  risks in the operation of shared IPv4/IPv6 networks, and document
>  operational practices to eliminate or mitigate those risks.  This
>  work will be done in cooperation with the Security area and other
>  relevant areas or working groups.
> 
> 5. Publish Informational or BCP RFCs that identify and analyze solutions
>  for deploying IPv6 within common network environments, such as
>  ISP Networks (including Core, HFC/Cable, DSL & Dial-up networks),
>  Enterprise Networks, Unmanaged Networks (Home/Small Office), and
>  Cellular Networks.
> 
>  These documents should serve as useful guides to network
>  operators and users on how to deploy IPv6 within their existing
>  IPv4 networks, as well as in new network installations.
> 
> 6. Identify open operational or security issues with the deployment
>  scenarios documented in (5) and fully document those open
>  issues in Internet-Drafts or Informational RFCs.
> 
> IPv6 operational and deployment issues with specific protocols or
> technologies (such as Applications, Transport Protocols, Routing
> Protocols, DNS or Sub-IP Protocols) are the primary responsibility of
> the groups or areas responsible for those protocols or technologies.
> However, the v6ops group will provide input to those areas/groups, as
> needed, and cooperate with those areas/groups in developing and
> reviewing solutions to IPv6 operational and deployment problems.
> 
> Specifying any protocols or transition mechanisms is out of scope of the WG.
> 
> Goals and Milestones:
> 
> Nov 04
> Adopt document describing how to use IPsec with draft-ietf-v6ops-mech-v2 as WG
> item
> Adopt document describing issues with NAT-PT as WG item
> Dec 04
> Adopt IPv6 Security Overview as WG item
> Adopt IPv6 deployment using VLANs as WG item
> 
> Jan 05
>                Adopt ISP IPv6 Deployment Scenarios in Broadband Access
> Networks as WG item
> Adopt IPv6 Network Architecture Protection as WG item
> 
> Feb 05
>                Submit IPv6-in-IPv4 Tunneling using IPsec to IESG for Info
> Submit IPv6 deployment using VLANs as WG item
> 
> Mar 05
>                Submit IPv6 Security Overview to IESG for Info
> Submit document describing issues with NAT-PT to IESG for Info
> Submit Enterprise Deployment Analysiss to IESG for Info
> 
> Apr 05        Submit IPv6 Network Architecture Protection to IESG for Info
> 
> May 05        Submit ISP IPv6 Deployment Scenarios in Broadband Access
Networks to 
> IESG for Info
> 
> 



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






From owner-v6ops@ops.ietf.org  Fri Nov 12 10:54:50 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14378
	for <v6ops-archive@lists.ietf.org>; Fri, 12 Nov 2004 10:54:49 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CSdjj-00098L-Va
	for v6ops-data@psg.com; Fri, 12 Nov 2004 15:53:19 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CSdjY-00095r-Vv
	for v6ops@ops.ietf.org; Fri, 12 Nov 2004 15:53:09 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id iACFr5I23191;
	Fri, 12 Nov 2004 17:53:05 +0200
Date: Fri, 12 Nov 2004 17:53:05 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
cc: v6ops@ops.ietf.org
Subject: Re: proposed new v6ops charter
In-Reply-To: <BDBA3BB2.4FB62%jordi.palet@consulintel.es>
Message-ID: <Pine.LNX.4.61.0411121740470.22831@netcore.fi>
References: <BDBA3BB2.4FB62%jordi.palet@consulintel.es>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

On Fri, 12 Nov 2004, JORDI PALET MARTINEZ wrote:
> I mostly agree with your proposed changes, but I've some concerns on number
> 6. I think it should stay as we have it now, because it already says that
> first we will try to do that work (if required), in the most appropriate WG,
> and only will be done in v6ops if there is not another option on that
> direction.

The point is that v6ops would, as written, just identify the issues, 
not act as a "mini-BoF" for solutions to those issues.  There are more 
generic avenues for that, and if something important comes along, 
rechartering is always possible, of course.

> Also not sure if 3 and 7 should be removed, even if the work is already
> done. May be to state that this has been already accomplished ? It seems to
> me that removing it is like "canceling" (or out-chartering) the work already
> done, which obviously is not what we want to do, right ? Note that I'm not
> opposing to this change, just will like to make sure that is the right way
> to proceed.

Umm.  So, what you suggest would be keeping the charter as is? 3, 6 
and 7 were the sections where there were changes :).

The work that has already been accomplished is typically taken out 
from cluttering the charter, and I see no issue with that.

> Finally, if we accept as a WG item (which I agree), the IPv6 NAP, then we
> should be fair and accept also, at least, the IPv6 Distributed Security
> problem statement and requirements documents.

IPv6 NAP is not accepted yet though there seemed to be strong support 
for it at the meeting.  Putting stuff on the milestones is no 
commitment one way or the other; especially, even if something wasn't 
in the milestones, it can still be added easily.

In the particular example you cite, the question would be whether 
those would be useful enough in this WG without a solution they call 
for, and if there is no solution, there is no sense in publishing them 
(as-is in any case).  From that perspective, I personally think these 
could form a core for a BoF to try to get those security geeks in the 
same room with v6 people who are worried about these issues.

-- 
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 owner-v6ops@ops.ietf.org  Fri Nov 12 11:23:28 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16957
	for <v6ops-archive@lists.ietf.org>; Fri, 12 Nov 2004 11:23:27 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CSeAp-000Cqw-IM
	for v6ops-data@psg.com; Fri, 12 Nov 2004 16:21:19 +0000
Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CSeAW-000CoY-7M
	for v6ops@ops.ietf.org; Fri, 12 Nov 2004 16:21:00 +0000
Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131])
	by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id iACGKxGn010591
	for <v6ops@ops.ietf.org>; Fri, 12 Nov 2004 16:20:59 GMT
Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162])
	by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id QAA20633
	for <v6ops@ops.ietf.org>; Fri, 12 Nov 2004 16:20:57 GMT
Received: (from tjc@localhost)
	by login.ecs.soton.ac.uk (8.11.6/8.11.6) id iACGKvj18965
	for v6ops@ops.ietf.org; Fri, 12 Nov 2004 16:20:57 GMT
Date: Fri, 12 Nov 2004 16:20:57 +0000
From: Tim Chown <tjc@ecs.soton.ac.uk>
To: v6ops@ops.ietf.org
Subject: Re: proposed new v6ops charter
Message-ID: <20041112162057.GD17725@login.ecs.soton.ac.uk>
Mail-Followup-To: v6ops@ops.ietf.org
References: <BDBA3BB2.4FB62%jordi.palet@consulintel.es> <Pine.LNX.4.61.0411121740470.22831@netcore.fi>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.61.0411121740470.22831@netcore.fi>
User-Agent: Mutt/1.4i
X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information
X-ECS-MailScanner: Found to be clean
X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

On Fri, Nov 12, 2004 at 05:53:05PM +0200, Pekka Savola wrote:
> 
> The point is that v6ops would, as written, just identify the issues, 
> not act as a "mini-BoF" for solutions to those issues.  There are more 
> generic avenues for that, and if something important comes along, 
> rechartering is always possible, of course.

Right, but I would assume drafts would be written to document the issues,
and those drafts become focuses for discussion.  An example might be the
onlink-by-default draft that Alain produced.  

Such drafts might then be published as Informational (bearing in mind Kurtis'
concern on "too many drafts"), or they could be used for the next revision
of an existing RFC, or they could just lead to modifications of a draft in 
progress in another WG, where the rationale is captured there.

In some cases the issue may not fit another WG, or an apparently appropriate
WG may not adopt the issue.   So I think we should have some valve in the
charter that does not prevent work being studied in v6ops if the WG approves
and a BoF/spin-out is not appropriate.  But I would hope that would be a
rare corner case.

I think the v6tc spin-out is working well, and I wouldn't like to see a v6ops
charter that prevented a similar spin-off in the future, so as long as the
"no mini-BoF" text allowed that, fine.

Tim



From owner-v6ops@ops.ietf.org  Fri Nov 12 11:25:33 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17449
	for <v6ops-archive@lists.ietf.org>; Fri, 12 Nov 2004 11:25:33 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CSeDl-000DHK-W0
	for v6ops-data@psg.com; Fri, 12 Nov 2004 16:24:21 +0000
Received: from [198.152.12.100] (helo=tiere.net.avaya.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CSeDb-000DEu-9P
	for v6ops@ops.ietf.org; Fri, 12 Nov 2004 16:24:11 +0000
Received: from tiere.net.avaya.com (localhost [127.0.0.1])
	by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id iACGMJEr000504
	for <v6ops@ops.ietf.org>; Fri, 12 Nov 2004 11:22:19 -0500 (EST)
Received: from nj7460avexu2.global.avaya.com (h198-152-6-52.avaya.com [198.152.6.52])
	by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id iACGLKEr029191
	for <v6ops@ops.ietf.org>; Fri, 12 Nov 2004 11:21:30 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: proposed new v6ops charter
Date: Fri, 12 Nov 2004 11:23:09 -0500
Message-ID: <5844A41F4E146044A2E8356C6328588007123591@nj7460avexu2.global.avaya.com>
Thread-Topic: proposed new v6ops charter
Thread-Index: AcTIvxJtY9wSuumvQEC5H07Fd+/rqwAE+cMA
From: "Yan, Li \(Li\)" <lyan@avaya.com>
To: "Pekka Savola" <pekkas@netcore.fi>, <v6ops@ops.ietf.org>
Cc: "Yan, Li \(Li\)" <lyan@avaya.com>
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

I missed the discussion on item3. Are we removing the itme3 because we
feel we don't have expertise or because we consider the work is done?

Thanks!

Li

-----Original Message-----
From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On
Behalf Of Pekka Savola
Sent: Friday, November 12, 2004 8:46 AM
To: v6ops@ops.ietf.org
Subject: proposed new v6ops charter

> - not put back the applications section, as that seems to been done=20
elsewhere, and the expertise is elsewhere.  This could be done as part=20
of ops work as well.

>- remove item 3 on application development and v4 dependencies
(already done)






From owner-v6ops@ops.ietf.org  Fri Nov 12 11:34:54 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18226
	for <v6ops-archive@lists.ietf.org>; Fri, 12 Nov 2004 11:34:53 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CSeMV-000Eal-PW
	for v6ops-data@psg.com; Fri, 12 Nov 2004 16:33:23 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CSeLY-000ERi-OO
	for v6ops@ops.ietf.org; Fri, 12 Nov 2004 16:32:25 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id iACGVgK24616;
	Fri, 12 Nov 2004 18:31:43 +0200
Date: Fri, 12 Nov 2004 18:31:42 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: "Yan, Li (Li)" <lyan@avaya.com>
cc: v6ops@ops.ietf.org
Subject: RE: proposed new v6ops charter
In-Reply-To: <5844A41F4E146044A2E8356C6328588007123591@nj7460avexu2.global.avaya.com>
Message-ID: <Pine.LNX.4.61.0411121829380.24157@netcore.fi>
References: <5844A41F4E146044A2E8356C6328588007123591@nj7460avexu2.global.avaya.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

Hi,

On Fri, 12 Nov 2004, Yan, Li (Li) wrote:
> I missed the discussion on item3. Are we removing the itme3 because we
> feel we don't have expertise or because we consider the work is done?

We've already done what we figured out (2-3 years ago) we should do.

We could be open to new proposals (though I don't recall seeing any), 
but I also feel this WG may not have sufficient apps expertise on 
this.

Maybe it is time to put the responsibility of IPv6 and applications on 
the applications area? ;-)

-- 
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 owner-v6ops@ops.ietf.org  Fri Nov 12 11:37:36 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18350
	for <v6ops-archive@lists.ietf.org>; Fri, 12 Nov 2004 11:37:36 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CSePX-000F40-JV
	for v6ops-data@psg.com; Fri, 12 Nov 2004 16:36:31 +0000
Received: from [66.218.78.101] (helo=web40404.mail.yahoo.com)
	by psg.com with smtp (Exim 4.41 (FreeBSD))
	id 1CSeOa-000Eu4-Jq
	for v6ops@ops.ietf.org; Fri, 12 Nov 2004 16:35:32 +0000
Received: (qmail 14236 invoked by uid 60001); 12 Nov 2004 16:35:32 -0000
Message-ID: <20041112163530.14225.qmail@web40404.mail.yahoo.com>
Received: from [67.164.86.168] by web40404.mail.yahoo.com via HTTP; Fri, 12 Nov 2004 08:35:30 PST
Date: Fri, 12 Nov 2004 08:35:30 -0800 (PST)
From: Pyda Srisuresh <srisuresh@yahoo.com>
Subject: Re: Consensus for moving NAT-PT to experimental?
To: Pekka Savola <pekkas@netcore.fi>, v6ops@ops.ietf.org
In-Reply-To: <Pine.LNX.4.61.0411111940140.25704@netcore.fi>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

Hi Pekka,

I disagree. NAT-PT is not experimental. There are customers with real use-case
scenarios that require and use the NAT-PT mechanism today. The NAT-PT use-case
scenarios have no other transition alternatives. Making the RFC experimental
does not make sense. 

As Tony and others pointed out in the past, the right thing to do would be to
revise the RFC to take out DNS-ALG sections and include use-case scenarios,
limitations and applicability statement.

regards,
suresh

--- Pekka Savola <pekkas@netcore.fi> wrote:

> Hi,
> 
> (co-chair hat on)
> 
> At the meeting, there was almost unanimous consensus for moving NAT-PT 
> to experimental.
> 
> The approach which seemed to have significant support was splitting 
> the document draft-aoun-v6ops-natpt-deprecate-00.txt in two: the one 
> describing issues (which would also request the reclassification), and 
> one describing different usage (or non-usage) scenarios.
> 
> If you believe this is a bad approach, please voice your concerns 
> within a week, by 18th November.  Thanks!
> 
> (hat off)
> 
> -- 
> 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 owner-v6ops@ops.ietf.org  Fri Nov 12 12:26:07 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22170
	for <v6ops-archive@lists.ietf.org>; Fri, 12 Nov 2004 12:26:07 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CSf9L-000LeO-SC
	for v6ops-data@psg.com; Fri, 12 Nov 2004 17:23:51 +0000
Received: from [198.152.12.100] (helo=tiere.net.avaya.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CSf9B-000Ldi-3r
	for v6ops@ops.ietf.org; Fri, 12 Nov 2004 17:23:41 +0000
Received: from tiere.net.avaya.com (localhost [127.0.0.1])
	by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id iACHLmEr024816
	for <v6ops@ops.ietf.org>; Fri, 12 Nov 2004 12:21:48 -0500 (EST)
Received: from nj7460avexu2.global.avaya.com (h198-152-6-52.avaya.com [198.152.6.52])
	by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id iACHK2Er022189
	for <v6ops@ops.ietf.org>; Fri, 12 Nov 2004 12:20:44 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: proposed new v6ops charter
Date: Fri, 12 Nov 2004 12:21:52 -0500
Message-ID: <5844A41F4E146044A2E8356C63285880071235E6@nj7460avexu2.global.avaya.com>
Thread-Topic: proposed new v6ops charter
Thread-Index: AcTI1TKcj3LteopPTz+mJ/7Vvlx0ngAAY+Zw
From: "Yan, Li \(Li\)" <lyan@avaya.com>
To: "Pekka Savola" <pekkas@netcore.fi>
Cc: <v6ops@ops.ietf.org>
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

I am ok with moving the item 3 out to APP. My only concern is that they
may not have v6 expertise like we have in this group. But I guess we
cannot have both anyway.

--Li

-----Original Message-----
From: Pekka Savola [mailto:pekkas@netcore.fi]=20
Sent: Friday, November 12, 2004 11:32 AM
To: Yan, Li (Li)
Cc: v6ops@ops.ietf.org
Subject: RE: proposed new v6ops charter

Hi,

On Fri, 12 Nov 2004, Yan, Li (Li) wrote:
> I missed the discussion on item3. Are we removing the itme3 because we
> feel we don't have expertise or because we consider the work is done?

We've already done what we figured out (2-3 years ago) we should do.

We could be open to new proposals (though I don't recall seeing any),=20
but I also feel this WG may not have sufficient apps expertise on=20
this.

Maybe it is time to put the responsibility of IPv6 and applications on=20
the applications area? ;-)

--=20
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 owner-v6ops@ops.ietf.org  Fri Nov 12 13:38:44 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00067
	for <v6ops-archive@lists.ietf.org>; Fri, 12 Nov 2004 13:38:43 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CSgH2-00056f-UO
	for v6ops-data@psg.com; Fri, 12 Nov 2004 18:35:52 +0000
Received: from [63.240.218.73] (helo=s-utl01-dcpop.stsn.com)
	by psg.com with smtp (Exim 4.41 (FreeBSD))
	id 1CSgGk-00055P-9U
	for v6ops@ops.ietf.org; Fri, 12 Nov 2004 18:35:34 +0000
Received: from dcpop.smtp.stsn.com ([127.0.0.1])
 by s-utl01-dcpop.stsn.com (SAVSMTP 3.1.0.29) with SMTP id M2004111213353203190
 for <v6ops@ops.ietf.org>; Fri, 12 Nov 2004 13:35:32 -0500
Received: from [10.67.86.36] ([10.67.86.36]) by dcpop.smtp.stsn.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Fri, 12 Nov 2004 13:35:32 -0500
User-Agent: Microsoft-Entourage/10.1.4.030702.0
Date: Fri, 12 Nov 2004 13:34:42 -0500
Subject: Re: proposed new v6ops charter
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: <v6ops@ops.ietf.org>
Message-ID: <BDBA6C72.4FC8C%jordi.palet@consulintel.es>
In-Reply-To: <Pine.LNX.4.61.0411121740470.22831@netcore.fi>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 12 Nov 2004 18:35:32.0868 (UTC) FILETIME=[64942440:01C4C8E6]
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Pekka,

I didn't want to keep 3 and 7. I just wondered if it makes sense to delete
something that we did, instead of including a note as "DONE". Anyway, is not
important, probably I never noticed this when other charters had been
updated and as you say is just ok removing both. I guess also an archive of
the previous versions of the charter should be available somewhere, for
clarity.

I agree that we should only identify the issues, but identifying the issues
should be open enough to host within the WG, as WG items, those documents
that analyze those issues.

Not sure why not the WG could act, if required, as a "mini-BoF" to charter
those solutions. What it will be wrong if we do that ? There is any rational
to avoid this which I'm missing ?

For the same reason, even if we don't provide a solution, should be fine to
describe an issue. I agree that in some cases a new WG is better (via BoF or
whatever), as we decided for the v6tc, but while that process doesn't move
forward, those documents should be WG documents. Otherwise, please, just
remove from the charter all the security thing, but not decide w/o a
consensus from the WG, that of course, should agree with the charter, what
is WG item and what's not. We started to change how we manage this, right ?
;-)

Regards,
Jordi


> De: Pekka Savola <pekkas@netcore.fi>
> Responder a: owner-v6ops@ops.ietf.org
> Fecha: Fri, 12 Nov 2004 17:53:05 +0200 (EET)
> Para: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
> CC: v6ops@ops.ietf.org
> Asunto: Re: proposed new v6ops charter
> 
> On Fri, 12 Nov 2004, JORDI PALET MARTINEZ wrote:
>> I mostly agree with your proposed changes, but I've some concerns on number
>> 6. I think it should stay as we have it now, because it already says that
>> first we will try to do that work (if required), in the most appropriate WG,
>> and only will be done in v6ops if there is not another option on that
>> direction.
> 
> The point is that v6ops would, as written, just identify the issues,
> not act as a "mini-BoF" for solutions to those issues.  There are more
> generic avenues for that, and if something important comes along,
> rechartering is always possible, of course.
> 
>> Also not sure if 3 and 7 should be removed, even if the work is already
>> done. May be to state that this has been already accomplished ? It seems to
>> me that removing it is like "canceling" (or out-chartering) the work already
>> done, which obviously is not what we want to do, right ? Note that I'm not
>> opposing to this change, just will like to make sure that is the right way
>> to proceed.
> 
> Umm.  So, what you suggest would be keeping the charter as is? 3, 6
> and 7 were the sections where there were changes :).
> 
> The work that has already been accomplished is typically taken out
> from cluttering the charter, and I see no issue with that.
> 
>> Finally, if we accept as a WG item (which I agree), the IPv6 NAP, then we
>> should be fair and accept also, at least, the IPv6 Distributed Security
>> problem statement and requirements documents.
> 
> IPv6 NAP is not accepted yet though there seemed to be strong support
> for it at the meeting.  Putting stuff on the milestones is no
> commitment one way or the other; especially, even if something wasn't
> in the milestones, it can still be added easily.
> 
> In the particular example you cite, the question would be whether
> those would be useful enough in this WG without a solution they call
> for, and if there is no solution, there is no sense in publishing them
> (as-is in any case).  From that perspective, I personally think these
> could form a core for a BoF to try to get those security geeks in the
> same room with v6 people who are worried about these issues.
> 
> -- 
> 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 owner-v6ops@ops.ietf.org  Fri Nov 12 14:31:03 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04556
	for <v6ops-archive@lists.ietf.org>; Fri, 12 Nov 2004 14:31:03 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CSh6n-000C07-CF
	for v6ops-data@psg.com; Fri, 12 Nov 2004 19:29:21 +0000
Received: from [144.254.15.119] (helo=strange-brew.cisco.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CSh6b-000Byv-SV
	for v6ops@ops.ietf.org; Fri, 12 Nov 2004 19:29:10 +0000
Received: from gvandeve-w2k01.cisco.com (ams-clip-vpn-dhcp4259.cisco.com [10.61.80.162])
	by strange-brew.cisco.com (8.11.7p1+Sun/8.8.8) with ESMTP id iACJT6119007;
	Fri, 12 Nov 2004 20:29:06 +0100 (CET)
Message-Id: <4.3.2.7.2.20041112194611.0581ef00@strange-brew>
X-Sender: gvandeve@strange-brew
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 12 Nov 2004 20:29:03 +0100
To: jordi.palet@consulintel.es
From: "Gunter Van de Velde (gvandeve)" <gvandeve@cisco.com>
Subject: Re: proposed new v6ops charter
Cc: <v6ops@ops.ietf.org>
In-Reply-To: <BDBA3BB2.4FB62%jordi.palet@consulintel.es>
References: <Pine.LNX.4.61.0411121536190.19151@netcore.fi>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

Hi Jordi,

<snip>

>Finally, if we accept as a WG item (which I agree), the IPv6 NAP, then we
>should be fair and accept also, at least, the IPv6 Distributed Security
>problem statement and requirements documents.
<end snip>

As Pekka mentioned, there was strong feeling during v6ops session on
'IPv6 NAP' adoption as WG item, i don't know the general feeling about
the IPv6 Distributed Security draft on the same question? It would be fair to
ask this question to the v6ops WG/chairs and check what the feeling is.

Brgds,
G/


At 10:06 12/11/2004 -0500, JORDI PALET MARTINEZ wrote:
>Hi Pekka, all,
>
>Thanks a lot for the openness in making this changes in the list. I think
>this is a very important sign of moving into a good direction.
>
>Now, get back to the work ;-)
>
>I mostly agree with your proposed changes, but I've some concerns on number
>6. I think it should stay as we have it now, because it already says that
>first we will try to do that work (if required), in the most appropriate WG,
>and only will be done in v6ops if there is not another option on that
>direction.
>
>Also not sure if 3 and 7 should be removed, even if the work is already
>done. May be to state that this has been already accomplished ? It seems to
>me that removing it is like "canceling" (or out-chartering) the work already
>done, which obviously is not what we want to do, right ? Note that I'm not
>opposing to this change, just will like to make sure that is the right way
>to proceed.
>
>Finally, if we accept as a WG item (which I agree), the IPv6 NAP, then we
>should be fair and accept also, at least, the IPv6 Distributed Security
>problem statement and requirements documents.
>
>Regards,
>Jordi
>
>
> > De: Pekka Savola <pekkas@netcore.fi>
> > Responder a: owner-v6ops@ops.ietf.org
> > Fecha: Fri, 12 Nov 2004 15:46:08 +0200 (EET)
> > Para: v6ops@ops.ietf.org
> > Asunto: proposed new v6ops charter
> >
> > Hi,
> >
> > (co-chair hat on)
> >
> > Below is the proposed draft charter for v6ops (I didn't renumber the
> > sections at this point) to narrow down the focus.
> >
> > This is roughly the same as presented at the meeting, with a couple of
> > comments/corrections:
> >
> > - clarify what "v6-in-v4 using IPsec" meant
> > - shift the milestone dates forward a little bit
> > - not change the statement on "all protocol work is outside of
> > scope": justification being that it may make sense to give out clearly
> > "the high-order bit" of what v6ops is (in principle) NOT doing
> > (without rechartering)
> > - not put back the applications section, as that seems to been done
> > elsewhere, and the expertise is elsewhere.  This could be done as part
> > of ops work as well.
> >
> > The charter proposal is below, and at the following URLs.
> >
> > http://netcore.fi/pekkas/ietf/temp/v6ops-dow.txt
> > http://netcore.fi/pekkas/ietf/temp/v6ops-dow.html (the diff)
> >
> > Comments?  Suggestions?  Please try to send them within a week or so.
> >
> > (hat off)
> > .................
> >
> > [[ the most important changes:
> >
> > - remove item 3 on application development and v4 dependencies
> > (already done)
> > - remove standardization of mechanisms from item 6
> > - remove responsibility of existing basic v6 transition mechanisms
> > - add new milestones and documents
> >
> > existing issues still:
> > - "operational/security issue" is still a blurry concept
> > - should _someone_ be responsible for the protocols? [this is not
> >   commonplace at IETF, though]
> > - the scenarios docs are still there, but they do not trigger any
> >   protocol work
> > ]]
> >
> > Description of Working Group:
> >
> > The global deployment of IPv6 is underway, creating an IPv4/IPv6
> > Internet consisting of IPv4-only, IPv6-only and IPv4/IPv6 networks and
> > nodes.  This deployment must be properly handled to avoid the division
> > of the Internet into separate IPv4 and IPv6 networks while ensuring
> > global addressing and connectivity for all IPv4 and IPv6 nodes.
> >
> > The IPv6 Operations Working Group (v6ops) develops guidelines for the
> > operation of a shared IPv4/IPv6 Internet and provides guidance for
> > network operators on how to deploy IPv6 into existing IPv4-only
> > networks, as well as into new network installations.
> >
> > The v6ops working group will:
> >
> > 1. Solicit input from network operators and users to identify
> >  operational or security issues with the IPv4/IPv6 Internet, and
> >  determine solutions or workarounds to those issues.  This includes
> >  identifying standards work that is needed in other IETF WGs or
> >  areas and working with those groups/areas to begin appropriate
> >  work.  These issues will be documented in Informational or BCP
> >  RFCs, or in Internet-Drafts.
> >
> >  For example, important pieces of the Internet infrastructure
> >  such as DNS, SMTP and SIP have specific operational issues when
> >  they operate in a shared IPv4/IPv6 network. The v6ops WG will
> >  cooperate with the relevant areas and WGs to document those
> >  issues, and find protocol or operational solutions to those
> >  problems.
> >
> > 2. Provide feedback to the IPv6 WG regarding portions of the IPv6
> >  specifications that cause, or are likely to cause, operational
> >  or security concerns, and work with the IPv6 WG to resolve
> >  those concerns.  This feedback will be published in
> >  Internet-Drafts or RFCs.
> >
> > 4. Publish Informational or BCP RFCs that identify potential security
> >  risks in the operation of shared IPv4/IPv6 networks, and document
> >  operational practices to eliminate or mitigate those risks.  This
> >  work will be done in cooperation with the Security area and other
> >  relevant areas or working groups.
> >
> > 5. Publish Informational or BCP RFCs that identify and analyze solutions
> >  for deploying IPv6 within common network environments, such as
> >  ISP Networks (including Core, HFC/Cable, DSL & Dial-up networks),
> >  Enterprise Networks, Unmanaged Networks (Home/Small Office), and
> >  Cellular Networks.
> >
> >  These documents should serve as useful guides to network
> >  operators and users on how to deploy IPv6 within their existing
> >  IPv4 networks, as well as in new network installations.
> >
> > 6. Identify open operational or security issues with the deployment
> >  scenarios documented in (5) and fully document those open
> >  issues in Internet-Drafts or Informational RFCs.
> >
> > IPv6 operational and deployment issues with specific protocols or
> > technologies (such as Applications, Transport Protocols, Routing
> > Protocols, DNS or Sub-IP Protocols) are the primary responsibility of
> > the groups or areas responsible for those protocols or technologies.
> > However, the v6ops group will provide input to those areas/groups, as
> > needed, and cooperate with those areas/groups in developing and
> > reviewing solutions to IPv6 operational and deployment problems.
> >
> > Specifying any protocols or transition mechanisms is out of scope of 
> the WG.
> >
> > Goals and Milestones:
> >
> > Nov 04
> > Adopt document describing how to use IPsec with 
> draft-ietf-v6ops-mech-v2 as WG
> > item
> > Adopt document describing issues with NAT-PT as WG item
> > Dec 04
> > Adopt IPv6 Security Overview as WG item
> > Adopt IPv6 deployment using VLANs as WG item
> >
> > Jan 05
> >                Adopt ISP IPv6 Deployment Scenarios in Broadband Access
> > Networks as WG item
> > Adopt IPv6 Network Architecture Protection as WG item
> >
> > Feb 05
> >                Submit IPv6-in-IPv4 Tunneling using IPsec to IESG for Info
> > Submit IPv6 deployment using VLANs as WG item
> >
> > Mar 05
> >                Submit IPv6 Security Overview to IESG for Info
> > Submit document describing issues with NAT-PT to IESG for Info
> > Submit Enterprise Deployment Analysiss to IESG for Info
> >
> > Apr 05        Submit IPv6 Network Architecture Protection to IESG for Info
> >
> > May 05        Submit ISP IPv6 Deployment Scenarios in Broadband Access
>Networks to
> > IESG for Info
> >
> >
>
>
>
>**********************************
>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.




From owner-v6ops@ops.ietf.org  Fri Nov 12 16:14:27 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24955
	for <v6ops-archive@lists.ietf.org>; Fri, 12 Nov 2004 16:14:27 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CSihh-00014l-Dq
	for v6ops-data@psg.com; Fri, 12 Nov 2004 21:11:33 +0000
Received: from [195.212.29.151] (helo=mtagate2.de.ibm.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CSihN-0000zN-In
	for v6ops@ops.ietf.org; Fri, 12 Nov 2004 21:11:14 +0000
Received: from d06nrmr1307.portsmouth.uk.ibm.com (d06nrmr1307.portsmouth.uk.ibm.com [9.149.38.129])
	by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id iACLB6xD213914;
	Fri, 12 Nov 2004 21:11:06 GMT
Received: from sihl.zurich.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216])
	by d06nrmr1307.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iACLB6Mr190726;
	Fri, 12 Nov 2004 21:11:06 GMT
Received: from zurich.ibm.com (sig-9-145-133-142.de.ibm.com [9.145.133.142])
	by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id WAA48176;
	Fri, 12 Nov 2004 22:11:01 +0100
Message-ID: <419526A7.2030601@zurich.ibm.com>
Date: Fri, 12 Nov 2004 22:09:59 +0100
From: Brian E Carpenter <brc@zurich.ibm.com>
Organization: IBM
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en, fr, de
MIME-Version: 1.0
To: Pyda Srisuresh <srisuresh@yahoo.com>
CC: Pekka Savola <pekkas@netcore.fi>, v6ops@ops.ietf.org
Subject: Re: Consensus for moving NAT-PT to experimental?
References: <20041112163530.14225.qmail@web40404.mail.yahoo.com>
In-Reply-To: <20041112163530.14225.qmail@web40404.mail.yahoo.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

> the right thing to do would be to
> revise the RFC to take out DNS-ALG sections and include use-case scenarios,
> limitations and applicability statement.

I understood that was the plan, but with the first step being
to reclassify the RFC to make it clear there are serious issues
with it. I support the reclassification.

     Brian

Pyda Srisuresh wrote:
> Hi Pekka,
> 
> I disagree. NAT-PT is not experimental. There are customers with real use-case
> scenarios that require and use the NAT-PT mechanism today. The NAT-PT use-case
> scenarios have no other transition alternatives. Making the RFC experimental
> does not make sense. 
> 
> As Tony and others pointed out in the past, the right thing to do would be to
> revise the RFC to take out DNS-ALG sections and include use-case scenarios,
> limitations and applicability statement.
> 
> regards,
> suresh
> 
> --- Pekka Savola <pekkas@netcore.fi> wrote:
> 
> 
>>Hi,
>>
>>(co-chair hat on)
>>
>>At the meeting, there was almost unanimous consensus for moving NAT-PT 
>>to experimental.
>>
>>The approach which seemed to have significant support was splitting 
>>the document draft-aoun-v6ops-natpt-deprecate-00.txt in two: the one 
>>describing issues (which would also request the reclassification), and 
>>one describing different usage (or non-usage) scenarios.
>>
>>If you believe this is a bad approach, please voice your concerns 
>>within a week, by 18th November.  Thanks!
>>
>>(hat off)
>>
>>-- 
>>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 owner-v6ops@ops.ietf.org  Fri Nov 12 16:27:04 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00969
	for <v6ops-archive@lists.ietf.org>; Fri, 12 Nov 2004 16:27:03 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CSivH-0002mD-Br
	for v6ops-data@psg.com; Fri, 12 Nov 2004 21:25:35 +0000
Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CSiuy-0002kr-IH
	for v6ops@ops.ietf.org; Fri, 12 Nov 2004 21:25:16 +0000
Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131])
	by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id iACLPFGn020480
	for <v6ops@ops.ietf.org>; Fri, 12 Nov 2004 21:25:15 GMT
Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162])
	by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id VAA29195
	for <v6ops@ops.ietf.org>; Fri, 12 Nov 2004 21:25:11 GMT
Received: (from tjc@localhost)
	by login.ecs.soton.ac.uk (8.11.6/8.11.6) id iACLPBC26008
	for v6ops@ops.ietf.org; Fri, 12 Nov 2004 21:25:11 GMT
Date: Fri, 12 Nov 2004 21:25:11 +0000
From: Tim Chown <tjc@ecs.soton.ac.uk>
To: v6ops@ops.ietf.org
Subject: Re: Consensus for moving NAT-PT to experimental?
Message-ID: <20041112212511.GA25815@login.ecs.soton.ac.uk>
Mail-Followup-To: v6ops@ops.ietf.org
References: <20041112163530.14225.qmail@web40404.mail.yahoo.com> <419526A7.2030601@zurich.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <419526A7.2030601@zurich.ibm.com>
User-Agent: Mutt/1.4i
X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information
X-ECS-MailScanner: Found to be clean
X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

On Fri, Nov 12, 2004 at 10:09:59PM +0100, Brian E Carpenter wrote:
> >the right thing to do would be to
> >revise the RFC to take out DNS-ALG sections and include use-case scenarios,
> >limitations and applicability statement.
> 
> I understood that was the plan, but with the first step being
> to reclassify the RFC to make it clear there are serious issues
> with it. I support the reclassification.
> 

I agree - a large health warning is required on NAT-PT as currently
described in the RFC.   But yes what you say is a likely path forward.

Tim



From owner-v6ops@ops.ietf.org  Fri Nov 12 16:57:26 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04950
	for <v6ops-archive@lists.ietf.org>; Fri, 12 Nov 2004 16:57:25 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CSjOf-0006j3-D7
	for v6ops-data@psg.com; Fri, 12 Nov 2004 21:55:57 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CSjOU-0006hW-GI
	for v6ops@ops.ietf.org; Fri, 12 Nov 2004 21:55:46 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id iACLtgr32688;
	Fri, 12 Nov 2004 23:55:42 +0200
Date: Fri, 12 Nov 2004 23:55:42 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
cc: v6ops@ops.ietf.org
Subject: Re: proposed new v6ops charter
In-Reply-To: <BDBA6C72.4FC8C%jordi.palet@consulintel.es>
Message-ID: <Pine.LNX.4.61.0411122351300.32319@netcore.fi>
References: <BDBA6C72.4FC8C%jordi.palet@consulintel.es>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

I'm only responding to a couple of issues because otherwise this 
seems to be getting to a rathole.  If you need more, we can discuss 
this off-list.

On Fri, 12 Nov 2004, JORDI PALET MARTINEZ wrote:
> I didn't want to keep 3 and 7. I just wondered if it makes sense to delete
> something that we did, instead of including a note as "DONE". Anyway, is not
> important, probably I never noticed this when other charters had been
> updated and as you say is just ok removing both. I guess also an archive of
> the previous versions of the charter should be available somewhere, for
> clarity.

It is, a snapshot at the time of a meeting is included in the 
proceedings.

> Not sure why not the WG could act, if required, as a "mini-BoF" to charter
> those solutions. What it will be wrong if we do that ? There is any rational
> to avoid this which I'm missing ?

Because one intent of a real BoF is to get together people who are 
interested in the subject (or opposed to the topic).  During it along 
the regular WG process loses that property.

-- 
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 owner-v6ops@ops.ietf.org  Fri Nov 12 17:02:44 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05789
	for <v6ops-archive@lists.ietf.org>; Fri, 12 Nov 2004 17:02:44 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CSjU6-0007hl-K7
	for v6ops-data@psg.com; Fri, 12 Nov 2004 22:01:34 +0000
Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CSjTv-0007fQ-Ke
	for v6ops@ops.ietf.org; Fri, 12 Nov 2004 22:01:23 +0000
Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131])
	by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id iACM1MGp021524
	for <v6ops@ops.ietf.org>; Fri, 12 Nov 2004 22:01:22 GMT
Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162])
	by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id WAA29520
	for <v6ops@ops.ietf.org>; Fri, 12 Nov 2004 22:01:18 GMT
Received: (from tjc@localhost)
	by login.ecs.soton.ac.uk (8.11.6/8.11.6) id iACM1Ip26803
	for v6ops@ops.ietf.org; Fri, 12 Nov 2004 22:01:18 GMT
Date: Fri, 12 Nov 2004 22:01:18 +0000
From: Tim Chown <tjc@ecs.soton.ac.uk>
To: v6ops@ops.ietf.org
Subject: Re: proposed new v6ops charter
Message-ID: <20041112220118.GD25815@login.ecs.soton.ac.uk>
Mail-Followup-To: v6ops@ops.ietf.org
References: <Pine.LNX.4.61.0411121536190.19151@netcore.fi>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.61.0411121536190.19151@netcore.fi>
User-Agent: Mutt/1.4i
X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information
X-ECS-MailScanner: Found to be clean
X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

On Fri, Nov 12, 2004 at 03:46:08PM +0200, Pekka Savola wrote:
>
>  - not change the statement on "all protocol work is outside of 
> scope": justification being that it may make sense to give out clearly 
> "the high-order bit" of what v6ops is (in principle) NOT doing 
> (without rechartering)

OK, so so long as that valve is there that's good; but main focus on the
operational.

>  - not put back the applications section, as that seems to been done 
> elsewhere, and the expertise is elsewhere.  This could be done as part 
> of ops work as well.

Since we have the app-aspects draft done, and the survey work done, I
agree this should be removed.   The only snag is that if app-specific 
issues arise, it's hard to say which apps WG they should be taken too.
But let's cross that bridge if/when we come to it, and leave the (identified
and done) apps work off charter.

>  - "operational/security issue" is still a blurry concept

Well, what do you see we should be doing?  And what do you plan to do
with draft-savola-v6ops-security-overview-03 for example?

>  - should _someone_ be responsible for the protocols? [this is not
>    commonplace at IETF, though]

What worries me a little is that N different WGs may (for example) devise
their own v6 tunneling methods for specific usage, where they could benefit
from a more unified approach.  Someone needs to play sweeper in the likely
groups where this sort of thing might happen, ideally before it then
emerges as an operational issue (interop, complexity, whatever).

>  - the scenarios docs are still there, but they do not trigger any
>    protocol work

So we need to look at all four analyses (three of which are in) and check
the gaps before we close off anything firmly, I think.  The v6tc area is
one such gap.  Do we have others?

> The global deployment of IPv6 is underway, creating an IPv4/IPv6
> Internet consisting of IPv4-only, IPv6-only and IPv4/IPv6 networks and
> nodes.  This deployment must be properly handled to avoid the division
> of the Internet into separate IPv4 and IPv6 networks while ensuring
> global addressing and connectivity for all IPv4 and IPv6 nodes.

Maybe emphasises that dual-stack is the likely norm (than 6-only) and
we should focus work on that for the next 1-3 years?

> The v6ops working group will:
> 
> 1. Solicit input from network operators and users to identify
>   operational or security issues with the IPv4/IPv6 Internet, and
>   determine solutions or workarounds to those issues.  This includes
>   identifying standards work that is needed in other IETF WGs or
>   areas and working with those groups/areas to begin appropriate
>   work.  These issues will be documented in Informational or BCP
>   RFCs, or in Internet-Drafts.

I think this is the main thrust.

> 2. Provide feedback to the IPv6 WG regarding portions of the IPv6
     ...

Agreed.

> 4. Publish Informational or BCP RFCs that identify potential security
>   risks in the operation of shared IPv4/IPv6 networks, and document
>   operational practices to eliminate or mitigate those risks.  This
>   work will be done in cooperation with the Security area and other
>   relevant areas or working groups.

I think 4 is kind of implied in 1 - maybe remove "or security" from
1 to leave it more general?
 
> 5. Publish Informational or BCP RFCs that identify and analyze solutions
>   for deploying IPv6 within common network environments, such as
    ....

Agree.
 
> 6. Identify open operational or security issues with the deployment
>   scenarios documented in (5) and fully document those open
>   issues in Internet-Drafts or Informational RFCs.

Again it kind of rehashes 1 and 4, as they stand.
 
> IPv6 operational and deployment issues with specific protocols or
> technologies (such as Applications, Transport Protocols, Routing
> Protocols, DNS or Sub-IP Protocols) are the primary responsibility of
> the groups or areas responsible for those protocols or technologies.
> However, the v6ops group will provide input to those areas/groups, as
> needed, and cooperate with those areas/groups in developing and
> reviewing solutions to IPv6 operational and deployment problems.

Clearly we need to push v6 to these groups, although it is probably well
considered by most already (some feedback on which groups need a bigger
push would be useful).  You could name some specific areas, like operation
of IPv6 Multicast with transition tools.

> Specifying any protocols or transition mechanisms is out of scope of the WG.

Maybe add a line as to how/where such work would be done?
 
> 		Adopt IPv6 Security Overview as WG item

Aha, that's your -03 doc?

Agree with all four adoptions.

I think Jordi's distributed-security text should be presented in the Security
are, as per Charter item 4.
 
>  Mar 05
>  		Submit Enterprise Deployment Analysiss to IESG for Info

Can we finish this sooner?  (Indeed, if there is no noew work in Charter
from this analysis, one could wonder how urgent it actually is.... we
do seem to be handwaving away whatevcer it might conclude?)
 
-- 
Tim



From owner-v6ops@ops.ietf.org  Fri Nov 12 18:53:01 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13731
	for <v6ops-archive@lists.ietf.org>; Fri, 12 Nov 2004 18:53:00 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CSlB7-000LuE-Mz
	for v6ops-data@psg.com; Fri, 12 Nov 2004 23:50:05 +0000
Received: from [66.218.78.103] (helo=web40406.mail.yahoo.com)
	by psg.com with smtp (Exim 4.41 (FreeBSD))
	id 1CSlAw-000Lrm-Uv
	for v6ops@ops.ietf.org; Fri, 12 Nov 2004 23:49:55 +0000
Received: (qmail 88010 invoked by uid 60001); 12 Nov 2004 23:49:54 -0000
Message-ID: <20041112234954.88008.qmail@web40406.mail.yahoo.com>
Received: from [63.145.234.162] by web40406.mail.yahoo.com via HTTP; Fri, 12 Nov 2004 15:49:54 PST
Date: Fri, 12 Nov 2004 15:49:54 -0800 (PST)
From: Pyda Srisuresh <srisuresh@yahoo.com>
Subject: Re: Consensus for moving NAT-PT to experimental?
To: Brian E Carpenter <brc@zurich.ibm.com>
Cc: Pekka Savola <pekkas@netcore.fi>, v6ops@ops.ietf.org
In-Reply-To: <419526A7.2030601@zurich.ibm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

OK, Got it. Thanks.

regards,
suresh

--- Brian E Carpenter <brc@zurich.ibm.com> wrote:

> > the right thing to do would be to
> > revise the RFC to take out DNS-ALG sections and include use-case scenarios,
> > limitations and applicability statement.
> 
> I understood that was the plan, but with the first step being
> to reclassify the RFC to make it clear there are serious issues
> with it. I support the reclassification.
> 
>      Brian
> 
> Pyda Srisuresh wrote:
> > Hi Pekka,
> > 
> > I disagree. NAT-PT is not experimental. There are customers with real
> use-case
> > scenarios that require and use the NAT-PT mechanism today. The NAT-PT
> use-case
> > scenarios have no other transition alternatives. Making the RFC
> experimental
> > does not make sense. 
> > 
> > As Tony and others pointed out in the past, the right thing to do would be
> to
> > revise the RFC to take out DNS-ALG sections and include use-case scenarios,
> > limitations and applicability statement.
> > 
> > regards,
> > suresh
> > 
> > --- Pekka Savola <pekkas@netcore.fi> wrote:
> > 
> > 
> >>Hi,
> >>
> >>(co-chair hat on)
> >>
> >>At the meeting, there was almost unanimous consensus for moving NAT-PT 
> >>to experimental.
> >>
> >>The approach which seemed to have significant support was splitting 
> >>the document draft-aoun-v6ops-natpt-deprecate-00.txt in two: the one 
> >>describing issues (which would also request the reclassification), and 
> >>one describing different usage (or non-usage) scenarios.
> >>
> >>If you believe this is a bad approach, please voice your concerns 
> >>within a week, by 18th November.  Thanks!
> >>
> >>(hat off)
> >>
> >>-- 
> >>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 owner-v6ops@ops.ietf.org  Sat Nov 13 06:56:06 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02142
	for <v6ops-archive@lists.ietf.org>; Sat, 13 Nov 2004 06:56:05 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CSwQi-000Edt-L8
	for v6ops-data@psg.com; Sat, 13 Nov 2004 11:50:56 +0000
Received: from [213.172.48.142] (helo=consulintel.es)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CSwQO-000EbX-T5
	for v6ops@ops.ietf.org; Sat, 13 Nov 2004 11:50:37 +0000
Received: from [10.40.10.28] ([80.248.40.77])
	by consulintel.es (consulintel.es [127.0.0.1])
	(MDaemon.PRO.v7.2.0.R)
	with ESMTP id md50000580748.msg
	for <v6ops@ops.ietf.org>; Sat, 13 Nov 2004 12:56:02 +0100
User-Agent: Microsoft-Entourage/10.1.4.030702.0
Date: Sat, 13 Nov 2004 12:46:56 +0100
Subject: Re: proposed new v6ops charter
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: <v6ops@ops.ietf.org>
Message-ID: <BDBBB2C0.4FD03%jordi.palet@consulintel.es>
In-Reply-To: <4.3.2.7.2.20041112194611.0581ef00@strange-brew>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Spam-Processed: consulintel.es, Sat, 13 Nov 2004 12:56:02 +0100
	(not processed: message from valid local sender)
X-MDRemoteIP: 80.248.40.77
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ops.ietf.org
Reply-To: jordi.palet@consulintel.es
X-MDAV-Processed: consulintel.es, Sat, 13 Nov 2004 12:56:08 +0100
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Gunter,

This is my point, if we ask the question for one document, because is within
the charter, we must ask the same question for other documents if they are
also in the charter ;-)

I understand that you mean that's the fair thing to do, right ?

Regards,
Jordi


> De: "Gunter Van de Velde (gvandeve)" <gvandeve@cisco.com>
> Responder a: owner-v6ops@ops.ietf.org
> Fecha: Fri, 12 Nov 2004 20:29:03 +0100
> Para: jordi.palet@consulintel.es
> CC: <v6ops@ops.ietf.org>
> Asunto: Re: proposed new v6ops charter
> 
> Hi Jordi,
> 
> <snip>
> 
>> Finally, if we accept as a WG item (which I agree), the IPv6 NAP, then we
>> should be fair and accept also, at least, the IPv6 Distributed Security
>> problem statement and requirements documents.
> <end snip>
> 
> As Pekka mentioned, there was strong feeling during v6ops session on
> 'IPv6 NAP' adoption as WG item, i don't know the general feeling about
> the IPv6 Distributed Security draft on the same question? It would be fair to
> ask this question to the v6ops WG/chairs and check what the feeling is.
> 
> Brgds,
> G/
> 
> 
> At 10:06 12/11/2004 -0500, JORDI PALET MARTINEZ wrote:
>> Hi Pekka, all,
>> 
>> Thanks a lot for the openness in making this changes in the list. I think
>> this is a very important sign of moving into a good direction.
>> 
>> Now, get back to the work ;-)
>> 
>> I mostly agree with your proposed changes, but I've some concerns on number
>> 6. I think it should stay as we have it now, because it already says that
>> first we will try to do that work (if required), in the most appropriate WG,
>> and only will be done in v6ops if there is not another option on that
>> direction.
>> 
>> Also not sure if 3 and 7 should be removed, even if the work is already
>> done. May be to state that this has been already accomplished ? It seems to
>> me that removing it is like "canceling" (or out-chartering) the work already
>> done, which obviously is not what we want to do, right ? Note that I'm not
>> opposing to this change, just will like to make sure that is the right way
>> to proceed.
>> 
>> Finally, if we accept as a WG item (which I agree), the IPv6 NAP, then we
>> should be fair and accept also, at least, the IPv6 Distributed Security
>> problem statement and requirements documents.
>> 
>> Regards,
>> Jordi
>> 
>> 
>>> De: Pekka Savola <pekkas@netcore.fi>
>>> Responder a: owner-v6ops@ops.ietf.org
>>> Fecha: Fri, 12 Nov 2004 15:46:08 +0200 (EET)
>>> Para: v6ops@ops.ietf.org
>>> Asunto: proposed new v6ops charter
>>> 
>>> Hi,
>>> 
>>> (co-chair hat on)
>>> 
>>> Below is the proposed draft charter for v6ops (I didn't renumber the
>>> sections at this point) to narrow down the focus.
>>> 
>>> This is roughly the same as presented at the meeting, with a couple of
>>> comments/corrections:
>>> 
>>> - clarify what "v6-in-v4 using IPsec" meant
>>> - shift the milestone dates forward a little bit
>>> - not change the statement on "all protocol work is outside of
>>> scope": justification being that it may make sense to give out clearly
>>> "the high-order bit" of what v6ops is (in principle) NOT doing
>>> (without rechartering)
>>> - not put back the applications section, as that seems to been done
>>> elsewhere, and the expertise is elsewhere.  This could be done as part
>>> of ops work as well.
>>> 
>>> The charter proposal is below, and at the following URLs.
>>> 
>>> http://netcore.fi/pekkas/ietf/temp/v6ops-dow.txt
>>> http://netcore.fi/pekkas/ietf/temp/v6ops-dow.html (the diff)
>>> 
>>> Comments?  Suggestions?  Please try to send them within a week or so.
>>> 
>>> (hat off)
>>> .................
>>> 
>>> [[ the most important changes:
>>> 
>>> - remove item 3 on application development and v4 dependencies
>>> (already done)
>>> - remove standardization of mechanisms from item 6
>>> - remove responsibility of existing basic v6 transition mechanisms
>>> - add new milestones and documents
>>> 
>>> existing issues still:
>>> - "operational/security issue" is still a blurry concept
>>> - should _someone_ be responsible for the protocols? [this is not
>>>   commonplace at IETF, though]
>>> - the scenarios docs are still there, but they do not trigger any
>>>   protocol work
>>> ]]
>>> 
>>> Description of Working Group:
>>> 
>>> The global deployment of IPv6 is underway, creating an IPv4/IPv6
>>> Internet consisting of IPv4-only, IPv6-only and IPv4/IPv6 networks and
>>> nodes.  This deployment must be properly handled to avoid the division
>>> of the Internet into separate IPv4 and IPv6 networks while ensuring
>>> global addressing and connectivity for all IPv4 and IPv6 nodes.
>>> 
>>> The IPv6 Operations Working Group (v6ops) develops guidelines for the
>>> operation of a shared IPv4/IPv6 Internet and provides guidance for
>>> network operators on how to deploy IPv6 into existing IPv4-only
>>> networks, as well as into new network installations.
>>> 
>>> The v6ops working group will:
>>> 
>>> 1. Solicit input from network operators and users to identify
>>>  operational or security issues with the IPv4/IPv6 Internet, and
>>>  determine solutions or workarounds to those issues.  This includes
>>>  identifying standards work that is needed in other IETF WGs or
>>>  areas and working with those groups/areas to begin appropriate
>>>  work.  These issues will be documented in Informational or BCP
>>>  RFCs, or in Internet-Drafts.
>>> 
>>>  For example, important pieces of the Internet infrastructure
>>>  such as DNS, SMTP and SIP have specific operational issues when
>>>  they operate in a shared IPv4/IPv6 network. The v6ops WG will
>>>  cooperate with the relevant areas and WGs to document those
>>>  issues, and find protocol or operational solutions to those
>>>  problems.
>>> 
>>> 2. Provide feedback to the IPv6 WG regarding portions of the IPv6
>>>  specifications that cause, or are likely to cause, operational
>>>  or security concerns, and work with the IPv6 WG to resolve
>>>  those concerns.  This feedback will be published in
>>>  Internet-Drafts or RFCs.
>>> 
>>> 4. Publish Informational or BCP RFCs that identify potential security
>>>  risks in the operation of shared IPv4/IPv6 networks, and document
>>>  operational practices to eliminate or mitigate those risks.  This
>>>  work will be done in cooperation with the Security area and other
>>>  relevant areas or working groups.
>>> 
>>> 5. Publish Informational or BCP RFCs that identify and analyze solutions
>>>  for deploying IPv6 within common network environments, such as
>>>  ISP Networks (including Core, HFC/Cable, DSL & Dial-up networks),
>>>  Enterprise Networks, Unmanaged Networks (Home/Small Office), and
>>>  Cellular Networks.
>>> 
>>>  These documents should serve as useful guides to network
>>>  operators and users on how to deploy IPv6 within their existing
>>>  IPv4 networks, as well as in new network installations.
>>> 
>>> 6. Identify open operational or security issues with the deployment
>>>  scenarios documented in (5) and fully document those open
>>>  issues in Internet-Drafts or Informational RFCs.
>>> 
>>> IPv6 operational and deployment issues with specific protocols or
>>> technologies (such as Applications, Transport Protocols, Routing
>>> Protocols, DNS or Sub-IP Protocols) are the primary responsibility of
>>> the groups or areas responsible for those protocols or technologies.
>>> However, the v6ops group will provide input to those areas/groups, as
>>> needed, and cooperate with those areas/groups in developing and
>>> reviewing solutions to IPv6 operational and deployment problems.
>>> 
>>> Specifying any protocols or transition mechanisms is out of scope of
>> the WG.
>>> 
>>> Goals and Milestones:
>>> 
>>> Nov 04
>>> Adopt document describing how to use IPsec with
>> draft-ietf-v6ops-mech-v2 as WG
>>> item
>>> Adopt document describing issues with NAT-PT as WG item
>>> Dec 04
>>> Adopt IPv6 Security Overview as WG item
>>> Adopt IPv6 deployment using VLANs as WG item
>>> 
>>> Jan 05
>>>                Adopt ISP IPv6 Deployment Scenarios in Broadband Access
>>> Networks as WG item
>>> Adopt IPv6 Network Architecture Protection as WG item
>>> 
>>> Feb 05
>>>                Submit IPv6-in-IPv4 Tunneling using IPsec to IESG for Info
>>> Submit IPv6 deployment using VLANs as WG item
>>> 
>>> Mar 05
>>>                Submit IPv6 Security Overview to IESG for Info
>>> Submit document describing issues with NAT-PT to IESG for Info
>>> Submit Enterprise Deployment Analysiss to IESG for Info
>>> 
>>> Apr 05        Submit IPv6 Network Architecture Protection to IESG for Info
>>> 
>>> May 05        Submit ISP IPv6 Deployment Scenarios in Broadband Access
>> Networks to
>>> IESG for Info
>>> 
>>> 
>> 
>> 
>> 
>> **********************************
>> 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.
> 
> 
> 



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






From owner-v6ops@ops.ietf.org  Sat Nov 13 06:56:21 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02164
	for <v6ops-archive@lists.ietf.org>; Sat, 13 Nov 2004 06:56:20 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CSwQS-000Ec9-Qm
	for v6ops-data@psg.com; Sat, 13 Nov 2004 11:50:40 +0000
Received: from [213.172.48.142] (helo=consulintel.es)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CSwQG-000EZy-JP
	for v6ops@ops.ietf.org; Sat, 13 Nov 2004 11:50:28 +0000
Received: from [10.40.10.28] ([80.248.40.77])
	by consulintel.es (consulintel.es [127.0.0.1])
	(MDaemon.PRO.v7.2.0.R)
	with ESMTP id md50000580747.msg
	for <v6ops@ops.ietf.org>; Sat, 13 Nov 2004 12:56:02 +0100
User-Agent: Microsoft-Entourage/10.1.4.030702.0
Date: Sat, 13 Nov 2004 12:42:28 +0100
Subject: Re: proposed new v6ops charter
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: <v6ops@ops.ietf.org>
Message-ID: <BDBBB1B4.4FD01%jordi.palet@consulintel.es>
In-Reply-To: <20041112220118.GD25815@login.ecs.soton.ac.uk>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Spam-Processed: consulintel.es, Sat, 13 Nov 2004 12:56:02 +0100
	(not processed: message from valid local sender)
X-MDRemoteIP: 80.248.40.77
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ops.ietf.org
Reply-To: jordi.palet@consulintel.es
X-MDAV-Processed: consulintel.es, Sat, 13 Nov 2004 12:56:07 +0100
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Tim,

FYI. The IPv6 distributed security has been presented in the security area
in IETF60, has been sent to their list, inputs had been requested, etc.,
etc., etc. No reply at all !

This is my fear about what it can happen with other works if they don't fit
in v6ops and are *ignored* by other WGs that should take care of it. Is an
issue, and probably requires some "mandate" from the IESG or IAB ?

Regards,
Jordi


> De: Tim Chown <tjc@ecs.soton.ac.uk>
> Responder a: owner-v6ops@ops.ietf.org
> Fecha: Fri, 12 Nov 2004 22:01:18 +0000
> Para: v6ops@ops.ietf.org
> Asunto: Re: proposed new v6ops charter
> 
> On Fri, Nov 12, 2004 at 03:46:08PM +0200, Pekka Savola wrote:
>> 
>>  - not change the statement on "all protocol work is outside of
>> scope": justification being that it may make sense to give out clearly
>> "the high-order bit" of what v6ops is (in principle) NOT doing
>> (without rechartering)
> 
> OK, so so long as that valve is there that's good; but main focus on the
> operational.
> 
>>  - not put back the applications section, as that seems to been done
>> elsewhere, and the expertise is elsewhere.  This could be done as part
>> of ops work as well.
> 
> Since we have the app-aspects draft done, and the survey work done, I
> agree this should be removed.   The only snag is that if app-specific
> issues arise, it's hard to say which apps WG they should be taken too.
> But let's cross that bridge if/when we come to it, and leave the (identified
> and done) apps work off charter.
> 
>>  - "operational/security issue" is still a blurry concept
> 
> Well, what do you see we should be doing?  And what do you plan to do
> with draft-savola-v6ops-security-overview-03 for example?
> 
>>  - should _someone_ be responsible for the protocols? [this is not
>>    commonplace at IETF, though]
> 
> What worries me a little is that N different WGs may (for example) devise
> their own v6 tunneling methods for specific usage, where they could benefit
> from a more unified approach.  Someone needs to play sweeper in the likely
> groups where this sort of thing might happen, ideally before it then
> emerges as an operational issue (interop, complexity, whatever).
> 
>>  - the scenarios docs are still there, but they do not trigger any
>>    protocol work
> 
> So we need to look at all four analyses (three of which are in) and check
> the gaps before we close off anything firmly, I think.  The v6tc area is
> one such gap.  Do we have others?
> 
>> The global deployment of IPv6 is underway, creating an IPv4/IPv6
>> Internet consisting of IPv4-only, IPv6-only and IPv4/IPv6 networks and
>> nodes.  This deployment must be properly handled to avoid the division
>> of the Internet into separate IPv4 and IPv6 networks while ensuring
>> global addressing and connectivity for all IPv4 and IPv6 nodes.
> 
> Maybe emphasises that dual-stack is the likely norm (than 6-only) and
> we should focus work on that for the next 1-3 years?
> 
>> The v6ops working group will:
>> 
>> 1. Solicit input from network operators and users to identify
>>   operational or security issues with the IPv4/IPv6 Internet, and
>>   determine solutions or workarounds to those issues.  This includes
>>   identifying standards work that is needed in other IETF WGs or
>>   areas and working with those groups/areas to begin appropriate
>>   work.  These issues will be documented in Informational or BCP
>>   RFCs, or in Internet-Drafts.
> 
> I think this is the main thrust.
> 
>> 2. Provide feedback to the IPv6 WG regarding portions of the IPv6
>    ...
> 
> Agreed.
> 
>> 4. Publish Informational or BCP RFCs that identify potential security
>>   risks in the operation of shared IPv4/IPv6 networks, and document
>>   operational practices to eliminate or mitigate those risks.  This
>>   work will be done in cooperation with the Security area and other
>>   relevant areas or working groups.
> 
> I think 4 is kind of implied in 1 - maybe remove "or security" from
> 1 to leave it more general?
> 
>> 5. Publish Informational or BCP RFCs that identify and analyze solutions
>>   for deploying IPv6 within common network environments, such as
>   ....
> 
> Agree.
> 
>> 6. Identify open operational or security issues with the deployment
>>   scenarios documented in (5) and fully document those open
>>   issues in Internet-Drafts or Informational RFCs.
> 
> Again it kind of rehashes 1 and 4, as they stand.
> 
>> IPv6 operational and deployment issues with specific protocols or
>> technologies (such as Applications, Transport Protocols, Routing
>> Protocols, DNS or Sub-IP Protocols) are the primary responsibility of
>> the groups or areas responsible for those protocols or technologies.
>> However, the v6ops group will provide input to those areas/groups, as
>> needed, and cooperate with those areas/groups in developing and
>> reviewing solutions to IPv6 operational and deployment problems.
> 
> Clearly we need to push v6 to these groups, although it is probably well
> considered by most already (some feedback on which groups need a bigger
> push would be useful).  You could name some specific areas, like operation
> of IPv6 Multicast with transition tools.
> 
>> Specifying any protocols or transition mechanisms is out of scope of the WG.
> 
> Maybe add a line as to how/where such work would be done?
> 
>> Adopt IPv6 Security Overview as WG item
> 
> Aha, that's your -03 doc?
> 
> Agree with all four adoptions.
> 
> I think Jordi's distributed-security text should be presented in the Security
> are, as per Charter item 4.
> 
>>  Mar 05
>> Submit Enterprise Deployment Analysiss to IESG for Info
> 
> Can we finish this sooner?  (Indeed, if there is no noew work in Charter
> from this analysis, one could wonder how urgent it actually is.... we
> do seem to be handwaving away whatevcer it might conclude?)
> 
> -- 
> Tim
> 
> 



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






From owner-v6ops@ops.ietf.org  Sun Nov 14 18:34:53 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21716
	for <v6ops-archive@lists.ietf.org>; Sun, 14 Nov 2004 18:34:52 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
	id 1CTTpB-0007KL-NH
	for v6ops-data@psg.com; Sun, 14 Nov 2004 23:30:25 +0000
Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CTTpA-0007K5-UP
	for v6ops@ops.ietf.org; Sun, 14 Nov 2004 23:30:25 +0000
Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131])
	by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id iAENUNGn003046
	for <v6ops@ops.ietf.org>; Sun, 14 Nov 2004 23:30:23 GMT
Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162])
	by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id XAA23816
	for <v6ops@ops.ietf.org>; Sun, 14 Nov 2004 23:30:22 GMT
Received: (from tjc@localhost)
	by login.ecs.soton.ac.uk (8.11.6/8.11.6) id iAENUM318710
	for v6ops@ops.ietf.org; Sun, 14 Nov 2004 23:30:22 GMT
Date: Sun, 14 Nov 2004 23:30:22 +0000
From: Tim Chown <tjc@ecs.soton.ac.uk>
To: v6ops@ops.ietf.org
Subject: Re: proposed new v6ops charter
Message-ID: <20041114233022.GD18457@login.ecs.soton.ac.uk>
Mail-Followup-To: v6ops@ops.ietf.org
References: <20041112220118.GD25815@login.ecs.soton.ac.uk> <BDBBB1B4.4FD01%jordi.palet@consulintel.es>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <BDBBB1B4.4FD01%jordi.palet@consulintel.es>
User-Agent: Mutt/1.4i
X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information
X-ECS-MailScanner: Found to be clean
X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=no 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

On Sat, Nov 13, 2004 at 12:42:28PM +0100, JORDI PALET MARTINEZ wrote:
> 
> FYI. The IPv6 distributed security has been presented in the security area
> in IETF60, has been sent to their list, inputs had been requested, etc.,
> etc., etc. No reply at all !
> 
> This is my fear about what it can happen with other works if they don't fit
> in v6ops and are *ignored* by other WGs that should take care of it. Is an
> issue, and probably requires some "mandate" from the IESG or IAB ?

One argument would be that if the security folks don't want to pick it up,
there's little chance of anything in the draft being taken forward and
implemented... i.e. the danger is that v6ops would create "white elephant"
solutions that people don't want.  We need an answer to that argument...
as it stands no reply = no interest.

In contrast, the NAP draft is an architectural document that describes how
the properties of v4+NAT can be achieved in IPv6 (and has identified some
gaps, such that the internal topology obfuscation, which Gunter has promised
some further thoughts on).   As such, it's an informational text that will
be cited as a useful BCP.

Tim



From owner-v6ops@ops.ietf.org  Mon Nov 15 13:41:34 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18824
	for <v6ops-archive@lists.ietf.org>; Mon, 15 Nov 2004 13:41:33 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
	id 1CTllA-0007lD-Hp
	for v6ops-data@psg.com; Mon, 15 Nov 2004 18:39:28 +0000
Received: from [192.71.80.74] (helo=laptop2.kurtis.pp.se)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CTll9-0007ky-Qm
	for v6ops@ops.ietf.org; Mon, 15 Nov 2004 18:39:28 +0000
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by laptop2.kurtis.pp.se (Postfix) with ESMTP
	id 2592B66C65A; Mon, 15 Nov 2004 19:39:27 +0100 (CET)
In-Reply-To: <BDBBB1B4.4FD01%jordi.palet@consulintel.es>
References: <BDBBB1B4.4FD01%jordi.palet@consulintel.es>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; format=fixed
Message-Id: <A58E842C-3735-11D9-818C-000A95928574@kurtis.pp.se>
Content-Transfer-Encoding: 7bit
Cc: <v6ops@ops.ietf.org>
From: Kurt Erik Lindqvist <kurtis@kurtis.pp.se>
Subject: Re: proposed new v6ops charter
Date: Mon, 15 Nov 2004 19:39:13 +0100
To: jordi.palet@consulintel.es
X-Pgp-Rfc2646-Fix: 1
X-Mailer: Apple Mail (2.619)
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=no 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On 2004-11-13, at 12.42, JORDI PALET MARTINEZ wrote:

> FYI. The IPv6 distributed security has been presented in the security 
> area
> in IETF60, has been sent to their list, inputs had been requested, 
> etc.,
> etc., etc. No reply at all !
>
> This is my fear about what it can happen with other works if they 
> don't fit
> in v6ops and are *ignored* by other WGs that should take care of it. 
> Is an
> issue, and probably requires some "mandate" from the IESG or IAB ?

As I said at the microphone in D.C, I think the issue then is to get 
the relevant groups interested rather than "let's do it anyway"....or 
maybe conclude that the particular work item (in general, not referring 
directly to you) perhaps is not interesting?

- - kurtis -

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.1

iQA/AwUBQZj326arNKXTPFCVEQK42QCdEX2XMrF6rYzIgxUA+kaDdBeje8MAmQEz
Neq+So+tVWA9+fv3m/5vC4ZC
=8EuQ
-----END PGP SIGNATURE-----




From owner-v6ops@ops.ietf.org  Mon Nov 15 16:01:24 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04090
	for <v6ops-archive@lists.ietf.org>; Mon, 15 Nov 2004 16:01:21 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
	id 1CTnwb-000L59-Gc
	for v6ops-data@psg.com; Mon, 15 Nov 2004 20:59:25 +0000
Received: from [213.172.48.142] (helo=consulintel.es)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CTnwa-000L4F-LZ
	for v6ops@ops.ietf.org; Mon, 15 Nov 2004 20:59:25 +0000
Received: from [10.0.102.45] ([80.248.40.77])
	by consulintel.es (consulintel.es [127.0.0.1])
	(MDaemon.PRO.v7.2.0.R)
	with ESMTP id md50000585389.msg
	for <v6ops@ops.ietf.org>; Mon, 15 Nov 2004 22:04:57 +0100
User-Agent: Microsoft-Entourage/10.1.4.030702.0
Date: Mon, 15 Nov 2004 21:59:06 +0100
Subject: Re: proposed new v6ops charter
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: <v6ops@ops.ietf.org>
Message-ID: <BDBED72A.50199%jordi.palet@consulintel.es>
In-Reply-To: <A58E842C-3735-11D9-818C-000A95928574@kurtis.pp.se>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Spam-Processed: consulintel.es, Mon, 15 Nov 2004 22:04:57 +0100
	(not processed: message from valid local sender)
X-MDRemoteIP: 80.248.40.77
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ops.ietf.org
Reply-To: jordi.palet@consulintel.es
X-MDAV-Processed: consulintel.es, Mon, 15 Nov 2004 22:05:04 +0100
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Kurtis,

Let's try to see it from another perspective.

Some people at v6ops believes is interesting and necessary to working in
topic "a". This topic fits very well in WG "x" charter, but WG "x", don't
care (may be they are not sufficiently aware about IPv6, or they have
already too much work, etc.). If the v6ops people can't convince (or they
don't have enough "participants" to be strong enough in WG "x"), this not
necessarily means that topic "a" is not interesting, right ? Is more a
question of newcomers with more work starting to participate in an existing
WG which is already busy ...

Regards,
Jordi

> De: Kurt Erik Lindqvist <kurtis@kurtis.pp.se>
> Responder a: owner-v6ops@ops.ietf.org
> Fecha: Mon, 15 Nov 2004 19:39:13 +0100
> Para: jordi.palet@consulintel.es
> CC: <v6ops@ops.ietf.org>
> Asunto: Re: proposed new v6ops charter
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> On 2004-11-13, at 12.42, JORDI PALET MARTINEZ wrote:
> 
>> FYI. The IPv6 distributed security has been presented in the security
>> area
>> in IETF60, has been sent to their list, inputs had been requested,
>> etc.,
>> etc., etc. No reply at all !
>> 
>> This is my fear about what it can happen with other works if they
>> don't fit
>> in v6ops and are *ignored* by other WGs that should take care of it.
>> Is an
>> issue, and probably requires some "mandate" from the IESG or IAB ?
> 
> As I said at the microphone in D.C, I think the issue then is to get
> the relevant groups interested rather than "let's do it anyway"....or
> maybe conclude that the particular work item (in general, not referring
> directly to you) perhaps is not interesting?
> 
> - - kurtis -
> 
> -----BEGIN PGP SIGNATURE-----
> Version: PGP 8.1
> 
> iQA/AwUBQZj326arNKXTPFCVEQK42QCdEX2XMrF6rYzIgxUA+kaDdBeje8MAmQEz
> Neq+So+tVWA9+fv3m/5vC4ZC
> =8EuQ
> -----END PGP SIGNATURE-----
> 
> 
> 



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






From owner-v6ops@ops.ietf.org  Mon Nov 15 16:29:44 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12305
	for <v6ops-archive@lists.ietf.org>; Mon, 15 Nov 2004 16:29:44 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
	id 1CToPS-000ODE-Pd
	for v6ops-data@psg.com; Mon, 15 Nov 2004 21:29:14 +0000
Received: from [66.54.152.27] (helo=jive.SoftHome.net)
	by psg.com with smtp (Exim 4.41 (FreeBSD))
	id 1CToPR-000OD1-SR
	for v6ops@ops.ietf.org; Mon, 15 Nov 2004 21:29:14 +0000
Received: (qmail 12889 invoked by uid 417); 15 Nov 2004 21:22:48 -0000
Received: from shunt-smtp-out-0 (HELO softhome.net) (172.16.3.12)
  by shunt-smtp-out-0 with SMTP; 15 Nov 2004 21:22:48 -0000
Received: from XPNERICK ([132.70.218.67])
  (AUTH: LOGIN ericlklein@softhome.net)
  by softhome.net with esmtp; Mon, 15 Nov 2004 14:22:46 -0700
Message-ID: <001301c4cb59$1bc21a90$0401a8c0@ttitelecom.com>
From: "EricLKlein" <ericlklein@softhome.net>
To: v6ops@ops.ietf.org
References: <BDBED72A.50199%jordi.palet@consulintel.es>
Subject: Re: proposed new v6ops charter
Date: Mon, 15 Nov 2004 23:21:42 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=no 
	version=2.64
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

> JORDI
> Let's try to see it from another perspective.
>
> Some people at v6ops believes is interesting and necessary to working in
> topic "a". This topic fits very well in WG "x" charter, but WG "x", don't
> care (may be they are not sufficiently aware about IPv6, or they have
> already too much work, etc.). If the v6ops people can't convince (or they
> don't have enough "participants" to be strong enough in WG "x"), this not
> necessarily means that topic "a" is not interesting, right ? Is more a
> question of newcomers with more work starting to participate in an
existing
> WG which is already busy ...
>
Maybe it is time that the people from V6Ops that feel this is important join
the security WG and start discussions there.
1. There is no real limit on WGs that you join, just limits on the time you
can contribute
2. Maybe if new people start talking and discussing this they will start to
understand and will start to work on it too.

Eric





From owner-v6ops@ops.ietf.org  Tue Nov 16 00:28:32 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04788
	for <v6ops-archive@lists.ietf.org>; Tue, 16 Nov 2004 00:28:31 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
	id 1CTvp7-0005wz-JS
	for v6ops-data@psg.com; Tue, 16 Nov 2004 05:24:13 +0000
Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com)
	by psg.com with esmtp (Exim 4.43 (FreeBSD))
	id 1CTvp6-0005wd-FL
	for v6ops@ops.ietf.org; Tue, 16 Nov 2004 05:24:12 +0000
Received: from esunmail ([129.147.156.34])
	by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id iAG5OCui020177
	for <v6ops@ops.ietf.org>; Mon, 15 Nov 2004 22:24:12 -0700 (MST)
Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM
 (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004))
 with ESMTP id <0I790019EB094M@edgemail1.Central.Sun.COM> for
 v6ops@ops.ietf.org; Mon, 15 Nov 2004 22:24:11 -0700 (MST)
Received: from [192.168.1.100] ([66.93.39.75])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004))
 with ESMTPSA id <0I79008Y0B07UT@mail.sun.net> for v6ops@ops.ietf.org; Mon,
 15 Nov 2004 22:24:09 -0700 (MST)
Date: Mon, 15 Nov 2004 21:24:06 -0800
From: Alain Durand <Alain.Durand@Sun.COM>
Subject: Re: proposed new v6ops charter
In-reply-to: <Pine.LNX.4.61.0411121536190.19151@netcore.fi>
To: Pekka Savola <pekkas@netcore.fi>,
        "'Soininen Jonne '" <jonne.soininen@nokia.com> (Nokia-NET/Helsinki),
        David Kessens <david@iprg.nokia.com>
Cc: "'v6ops@ops.ietf.org '" <v6ops@ops.ietf.org>
Message-id: <BC8CDA16-378F-11D9-9C01-00039358A080@sun.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.619)
Content-type: text/plain; charset=US-ASCII; format=flowed
Content-transfer-encoding: 7BIT
References: <Pine.LNX.4.61.0411121536190.19151@netcore.fi>
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham 
	version=3.0.1
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7BIT


> The v6ops working group will:
>
> 1. Solicit input from network operators and users to identify
>   operational or security issues with the IPv4/IPv6 Internet, and
>   determine solutions or workarounds to those issues.  This includes
>   identifying standards work that is needed in other IETF WGs or
>   areas and working with those groups/areas to begin appropriate
>   work.  These issues will be documented in Informational or BCP
>   RFCs, or in Internet-Drafts.

Yes.

>   For example, important pieces of the Internet infrastructure
>   such as DNS, SMTP and SIP have specific
> operational issues when
>   they operate in a shared IPv4/IPv6 network. The v6ops WG will
>   cooperate with the relevant areas and WGs to document those
>   issues, and find protocol or operational solutions to those
>   problems.

DNS IPv6 issues are well handled by DNSop, my understanding was
that one of the SIP wg is eventually talking about v4/v6 coexistence
and I'm not sure anymore about the fate of v6 SMTP.

My point is that those examples should be removed as they are NOT being
addressed by the v6OPS wg, neither in the recent past nor in the 
proposed
milestones.

> 2. Provide feedback to the IPv6 WG regarding portions of the IPv6
>   specifications that cause, or are likely to cause, operational
>   or security concerns, and work with the IPv6 WG to resolve
>   those concerns.  This feedback will be published in
>   Internet-Drafts or RFCs.

If you remove the specific examples, there is then no reason to single 
out
the IPv6 wg from the rest of the IETF.


> 4. Publish Informational or BCP RFCs that identify potential security
>   risks in the operation of shared IPv4/IPv6 networks, and document
>   operational practices to eliminate or mitigate those risks.  This
>   work will be done in cooperation with the Security area and other
>   relevant areas or working groups.

Again, this could be folded in 1).

> 5. Publish Informational or BCP RFCs that identify and analyze 
> solutions
>   for deploying IPv6 within common network environments, such as
>   ISP Networks (including Core, HFC/Cable, DSL & Dial-up networks),
>   Enterprise Networks, Unmanaged Networks (Home/Small Office), and
>   Cellular Networks.
>
>   These documents should serve as useful guides to network
>   operators and users on how to deploy IPv6 within their existing
>   IPv4 networks, as well as in new network installations.

I thought we were done with that.

> 6. Identify open operational or security issues with the deployment
>   scenarios documented in (5) and fully document those open
>   issues in Internet-Drafts or Informational RFCs.

ditto.

> IPv6 operational and deployment issues with specific protocols or
> technologies (such as Applications, Transport Protocols, Routing
> Protocols, DNS or Sub-IP Protocols) are the primary responsibility of
> the groups or areas responsible for those protocols or technologies.
> However, the v6ops group will provide input to those areas/groups, as
> needed, and cooperate with those areas/groups in developing and
> reviewing solutions to IPv6 operational and deployment problems.
>
> Specifying any protocols or transition mechanisms is out of scope of 
> the WG.
>
> Goals and Milestones:
>
>  Nov 04
> 		Adopt document describing how to use IPsec with 
> draft-ietf-v6ops-mech-v2 as WG item
> 		Adopt document describing issues with NAT-PT as WG item
>  Dec 04
> 		Adopt IPv6 Security Overview as WG item
> 		Adopt IPv6 deployment using VLANs as WG item
>
>  Jan 05
>                 Adopt ISP IPv6 Deployment Scenarios in Broadband 
> Access Networks as WG item
> 		Adopt IPv6 Network Architecture Protection as WG item
>
>  Feb 05
>                 Submit IPv6-in-IPv4 Tunneling using IPsec to IESG for 
> Info
> 		Submit IPv6 deployment using VLANs as WG item
>
>  Mar 05
>                 Submit IPv6 Security Overview to IESG for Info
> 		Submit document describing issues with NAT-PT to IESG for Info
>  		Submit Enterprise Deployment Analysiss to IESG for Info
>
>  Apr 05		Submit IPv6 Network Architecture Protection to IESG for Info
>
>  May 05		Submit ISP IPv6 Deployment Scenarios in Broadband Access 
> Networks to IESG for Info

I do not see any milestones about the work on v6onbydefault, arguably 
the few pieces
of real ops feedback that was worked on in this wg along DNS issues.

To up-level this discussion, my feedback to the chairs and the AD is 
that v6ops should focus more on ops issues.
The target of this wg should be to document in RFCs issues that came 
during deployment with suggested workaround
and/or send draft in the relevant wg when something need to be changed 
in protocol specs.

Another piece of work that is of interest is collecting feedback from 
folks doing real deployment and using
the transition toolbox we have since NGtrans. Documenting what works 
and what does not would be very valuable.

IMHO, anything else should be out of scope.

	- Alain.




From owner-v6ops@ops.ietf.org  Tue Nov 16 02:56:46 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00599
	for <v6ops-archive@lists.ietf.org>; Tue, 16 Nov 2004 02:56:46 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
	id 1CTyAb-000KIU-0n
	for v6ops-data@psg.com; Tue, 16 Nov 2004 07:54:33 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.43 (FreeBSD))
	id 1CTyAZ-000KHx-Hq
	for v6ops@ops.ietf.org; Tue, 16 Nov 2004 07:54:32 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id iAG7sNL05591;
	Tue, 16 Nov 2004 09:54:23 +0200
Date: Tue, 16 Nov 2004 09:54:22 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: Alain Durand <Alain.Durand@Sun.COM>
cc: "'Soininen Jonne '" <jonne.soininen@nokia.com>,
        David Kessens <david@iprg.nokia.com>,
        "'v6ops@ops.ietf.org '" <v6ops@ops.ietf.org>
Subject: Re: proposed new v6ops charter
In-Reply-To: <BC8CDA16-378F-11D9-9C01-00039358A080@sun.com>
Message-ID: <Pine.LNX.4.61.0411160933400.4177@netcore.fi>
References: <Pine.LNX.4.61.0411121536190.19151@netcore.fi>
 <BC8CDA16-378F-11D9-9C01-00039358A080@sun.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham 
	version=3.0.1
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

On Mon, 15 Nov 2004, Alain Durand wrote:
>>   For example, important pieces of the Internet infrastructure
>>   such as DNS, SMTP and SIP have specific
>> operational issues when
>>   they operate in a shared IPv4/IPv6 network. The v6ops WG will
>>   cooperate with the relevant areas and WGs to document those
>>   issues, and find protocol or operational solutions to those
>>   problems.
>
> DNS IPv6 issues are well handled by DNSop, my understanding was
> that one of the SIP wg is eventually talking about v4/v6 coexistence
> and I'm not sure anymore about the fate of v6 SMTP.
>
> My point is that those examples should be removed as they are NOT being
> addressed by the v6OPS wg, neither in the recent past nor in the proposed
> milestones.

Do you have further examples in mind to talk about here?  IMHO, it's 
good to have examples, and I didn't remove them (even if they were 
done) because they were illustrating which kind of issues the charter 
was referring to.

>> 2. Provide feedback to the IPv6 WG regarding portions of the IPv6
>>   specifications that cause, or are likely to cause, operational
>>   or security concerns, and work with the IPv6 WG to resolve
>>   those concerns.  This feedback will be published in
>>   Internet-Drafts or RFCs.
>
> If you remove the specific examples, there is then no reason to single out
> the IPv6 wg from the rest of the IETF.

Agreed, though the item 2 has slightly different focus as I read it. 
It seems to say, "check and keep checking the existing IPv6 
specifications that they work OK", while item 1 seems to say "identify 
missing pieces which need new work".

>> 4. Publish Informational or BCP RFCs that identify potential security
>>   risks in the operation of shared IPv4/IPv6 networks, and document
>>   operational practices to eliminate or mitigate those risks.  This
>>   work will be done in cooperation with the Security area and other
>>   relevant areas or working groups.
>
> Again, this could be folded in 1).

True, if item 1 is made generic -- there is a danger in too much 
genericity that one forgets which specific kinds of tasks (like 2 and 
4 here) have been put forward to the WG.

>> 5. Publish Informational or BCP RFCs that identify and analyze solutions
>>   for deploying IPv6 within common network environments, such as
>>   ISP Networks (including Core, HFC/Cable, DSL & Dial-up networks),
>>   Enterprise Networks, Unmanaged Networks (Home/Small Office), and
>>   Cellular Networks.
>> 
>>   These documents should serve as useful guides to network
>>   operators and users on how to deploy IPv6 within their existing
>>   IPv4 networks, as well as in new network installations.
>
> I thought we were done with that.

What do you call the campus transition document then?  Granted the 
text in the second paragraph should be tweaked a bit to fit.

Another related document was the description of broadband ISP IPv6 
deployment efforts.

It's not like we want to do a lot more of the scenarios documents, and 
we certainly don't want to go down the analysis path, but if someone 
wants to do a document describing IPv6 deployment scenario, is there a 
good reason to rule it out?

> I do not see any milestones about the work on v6onbydefault, 
> arguably the few pieces of real ops feedback that was worked on in 
> this wg along DNS issues.

The v6onbydefault work is close to done and going forward as it is so 
there is no need to call it out here, AFAICS.

If you refer to some other potential work items relating or close to 
"v6onbydefault", feel free to suggest them.  I'd expect those are just 
ones that will come up when folks think of something.

> To up-level this discussion, my feedback to the chairs and the AD is 
> that v6ops should focus more on ops issues. The target of this wg 
> should be to document in RFCs issues that came during deployment 
> with suggested workaround and/or send draft in the relevant wg when 
> something need to be changed in protocol specs.

"Issues that come during deployment" can be interpreted either widely 
or narrowly.   And depending on that..

> IMHO, anything else should be out of scope.

.. is also a very generic statement, so it's not all that useful in 
practice.

To keep this practical, do you think some of those proposed 
deliverables explicitly mentioned in the draft charter would be 
inappropriate for the scope of this WG?

Or do you have suggestions for deliverables which should be more in 
scope which might help in illustrating which kind of documents you 
refer (and not refer) to?

If we project the draft charter you'd like to see to documents 
produced by this WG, or proposed to this WG, as concrete examples, 
which do you should have been or be in scope:
  - draft-ietf-v6ops-renumbering-procedure
  - draft-ietf-v6ops-6to4-security
  - draft-ietf-v6ops-application-transition
  - the scenarios documents we did
  - the analysis documents we did
  - draft-chown-v6ops-campus-transition
  - draft-larsson-v6ops-mip-scenarios
  - draft-asadullah-v6ops-bb-deployment-scenarios
  - draft-ietf-v6ops-v6onbydefault
  - draft-ietf-v6ops-mech-v2
  - draft-aoun-v6ops-natpt-deprecate
  - draft-chown-v6ops-port-scanning-implications
  - draft-chown-v6ops-renumber-thinkabout
  - draft-chown-v6ops-vlan-usage
  - draft-savola-v6ops-security-overview
  - draft-vandevelde-v6ops-nap
  - draft-tschofenig-v6ops-secure-tunnels
  - Jordi et al's distributed security work

Let's not talk too vaguely because then nobody can understand what 
each other is saying, because "let's do operational stuff" is a very 
generic statement :)

I think I hear loud and clear that you want to see documents like 
campus transition, e.g., describing how the transition mechanisms work 
or don't, and issues brought up relating to deployment, e.g., as was 
done in v6onbydefault.  I think the current draft charter is open to 
those.  But what else would you feel would be OK?  Note that if those 
would be the only kind of work to be done, the proposed deliverables 
list might look close to empty.

-- 
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 owner-v6ops@ops.ietf.org  Tue Nov 16 03:15:52 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02787
	for <v6ops-archive@lists.ietf.org>; Tue, 16 Nov 2004 03:15:52 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
	id 1CTyUp-000Mhh-O3
	for v6ops-data@psg.com; Tue, 16 Nov 2004 08:15:27 +0000
Received: from [192.71.80.74] (helo=laptop2.kurtis.pp.se)
	by psg.com with esmtp (Exim 4.43 (FreeBSD))
	id 1CTyUo-000MhQ-TX
	for v6ops@ops.ietf.org; Tue, 16 Nov 2004 08:15:27 +0000
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by laptop2.kurtis.pp.se (Postfix) with ESMTP
	id 0640866FD2F; Tue, 16 Nov 2004 09:15:31 +0100 (CET)
In-Reply-To: <BDBED72A.50199%jordi.palet@consulintel.es>
References: <BDBED72A.50199%jordi.palet@consulintel.es>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; format=fixed
Message-Id: <AA4EB3F0-37A7-11D9-818C-000A95928574@kurtis.pp.se>
Content-Transfer-Encoding: 7bit
Cc: <v6ops@ops.ietf.org>
From: Kurt Erik Lindqvist <kurtis@kurtis.pp.se>
Subject: Re: proposed new v6ops charter
Date: Tue, 16 Nov 2004 09:15:24 +0100
To: jordi.palet@consulintel.es
X-Pgp-Rfc2646-Fix: 1
X-Mailer: Apple Mail (2.619)
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham 
	version=3.0.1
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On 2004-11-15, at 21.59, JORDI PALET MARTINEZ wrote:
> Let's try to see it from another perspective.
>
> Some people at v6ops believes is interesting and necessary to working 
> in
> topic "a". This topic fits very well in WG "x" charter, but WG "x", 
> don't
> care (may be they are not sufficiently aware about IPv6, or they have
> already too much work, etc.). If the v6ops people can't convince (or 
> they
> don't have enough "participants" to be strong enough in WG "x"), this 
> not
> necessarily means that topic "a" is not interesting, right ? Is more a
> question of newcomers with more work starting to participate in an 
> existing
> WG which is already busy ...

I just fail to see what issues around IPv6 would be so special that it 
needs special treatment and can't be handled in the respective areas? 
If I come up with this really interesting security problem in IPv4, and 
the security area does show any interest at all or are too overworked, 
can I then set up the v4ops and discuss it there?

If a certain area in the IETF is overloaded or unaware of IPv6, then 
THOSE are the problems we need to address. Not pushing ahead at any 
cost somewhere else.

- - kurtis -

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.1

iQA/AwUBQZm3IaarNKXTPFCVEQIRwwCfRoRI9rt8KgfeSK7T/9fTm+7fHIIAnAmG
M0uqzFiLogNaoWCJxoST6zfD
=guGg
-----END PGP SIGNATURE-----




From owner-v6ops@ops.ietf.org  Tue Nov 16 06:40:13 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18174
	for <v6ops-archive@lists.ietf.org>; Tue, 16 Nov 2004 06:40:13 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
	id 1CU1eg-000FqX-P2
	for v6ops-data@psg.com; Tue, 16 Nov 2004 11:37:50 +0000
Received: from [131.228.20.21] (helo=mgw-x1.nokia.com)
	by psg.com with esmtp (Exim 4.43 (FreeBSD))
	id 1CU1eT-000FpK-2K
	for v6ops@ops.ietf.org; Tue, 16 Nov 2004 11:37:37 +0000
Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120])
	by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iAGBbYv01097;
	Tue, 16 Nov 2004 13:37:35 +0200 (EET)
X-Scanned: Tue, 16 Nov 2004 13:34:15 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE
Received: (from root@localhost)
	by esdks001.ntc.nokia.com (8.12.9/8.12.9) id iAGBYF52030260;
	Tue, 16 Nov 2004 13:34:15 +0200
Received: from mgw-int2.ntc.nokia.com (172.21.143.97)
	by esdks001.ntc.nokia.com 00KCETrW; Tue, 16 Nov 2004 13:34:13 EET
Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28])
	by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iAGBWCS28812;
	Tue, 16 Nov 2004 13:32:12 +0200 (EET)
Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881);
	 Tue, 16 Nov 2004 13:32:09 +0200
Received: from esebe009.NOE.Nokia.com ([172.21.138.41]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881);
	 Tue, 16 Nov 2004 13:32:09 +0200
Received: from esebe054.NOE.Nokia.com ([172.21.143.44]) by esebe009.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881);
	 Tue, 16 Nov 2004 13:32:09 +0200
Received: ESEBE054.noe.nokia.com 172.21.143.44 from 172.21.155.64 172.21.155.64 via HTTP with MS-WebStorage 6.0.6249
Received: from essrv103nok15564.ntc.nokia.com by ESEBE054.noe.nokia.com; 16 Nov 2004 13:32:08 +0200
Subject: Re: proposed new v6ops charter
From: "Soininen Jonne (Nokia-NET/Helsinki)" <jonne.soininen@nokia.com>
To: ext Kurt Erik Lindqvist <kurtis@kurtis.pp.se>
Cc: jordi.palet@consulintel.es, v6ops@ops.ietf.org
In-Reply-To: <AA4EB3F0-37A7-11D9-818C-000A95928574@kurtis.pp.se>
References: <BDBED72A.50199%jordi.palet@consulintel.es>
	 <AA4EB3F0-37A7-11D9-818C-000A95928574@kurtis.pp.se>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1100604728.10092.16.camel@essrv103nok15564.ntc.nokia.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.6 
Date: Tue, 16 Nov 2004 13:32:08 +0200
X-OriginalArrivalTime: 16 Nov 2004 11:32:09.0943 (UTC) FILETIME=[E8E86670:01C4CBCF]
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham 
	version=3.0.1
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi,

generally, I kind of agree with Kurt. Let's not duplicate work in v6ops
and hope that other people find it useful after we are done. We really
do have to address the issues that belong to a specific WG in that WG.
If the work is not taken up there, it may be that they are busy/not
interested/etc. However, we have to take into account the possibility
that we didn't understand something, too.

Cheers,

Jonne.

On Tue, 2004-11-16 at 10:15, ext Kurt Erik Lindqvist wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> On 2004-11-15, at 21.59, JORDI PALET MARTINEZ wrote:
> > Let's try to see it from another perspective.
> >
> > Some people at v6ops believes is interesting and necessary to working 
> > in
> > topic "a". This topic fits very well in WG "x" charter, but WG "x", 
> > don't
> > care (may be they are not sufficiently aware about IPv6, or they have
> > already too much work, etc.). If the v6ops people can't convince (or 
> > they
> > don't have enough "participants" to be strong enough in WG "x"), this 
> > not
> > necessarily means that topic "a" is not interesting, right ? Is more a
> > question of newcomers with more work starting to participate in an 
> > existing
> > WG which is already busy ...
> 
> I just fail to see what issues around IPv6 would be so special that it 
> needs special treatment and can't be handled in the respective areas? 
> If I come up with this really interesting security problem in IPv4, and 
> the security area does show any interest at all or are too overworked, 
> can I then set up the v4ops and discuss it there?
> 
> If a certain area in the IETF is overloaded or unaware of IPv6, then 
> THOSE are the problems we need to address. Not pushing ahead at any 
> cost somewhere else.
> 
> - - kurtis -
> 
> -----BEGIN PGP SIGNATURE-----
> Version: PGP 8.1
> 
> iQA/AwUBQZm3IaarNKXTPFCVEQIRwwCfRoRI9rt8KgfeSK7T/9fTm+7fHIIAnAmG
> M0uqzFiLogNaoWCJxoST6zfD
> =guGg
> -----END PGP SIGNATURE-----
-- 
Jonne Soininen
Nokia

Tel: +358 40 527 46 34
E-mail: jonne.soininen@nokia.com



From owner-v6ops@ops.ietf.org  Tue Nov 16 08:59:42 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29964
	for <v6ops-archive@lists.ietf.org>; Tue, 16 Nov 2004 08:59:42 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
	id 1CU3qV-0004ZT-48
	for v6ops-data@psg.com; Tue, 16 Nov 2004 13:58:11 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.43 (FreeBSD))
	id 1CU3qQ-0004Yp-HP
	for v6ops@ops.ietf.org; Tue, 16 Nov 2004 13:58:07 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id iAGDw4b14507
	for <v6ops@ops.ietf.org>; Tue, 16 Nov 2004 15:58:04 +0200
Date: Tue, 16 Nov 2004 15:58:04 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: v6ops@ops.ietf.org
Subject: IETF61 draft minutes + slides
Message-ID: <Pine.LNX.4.61.0411161553410.14414@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham 
	version=3.0.1
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

Hi,

(co-chair hat on)

The draft minutes + slides (except for one missing presentation, yet) 
are complete at:

http://www.netcore.fi/pekkas/ietf/61/IETF61-v6ops-minutes.txt
http://www.netcore.fi/pekkas/ietf/61/0*.pdf (slides)

Please send corrections, additions, etc. preferably this week, after 
which I'll push these to the proceedings.

Remember that it's important that the minutes are accurate as these 
are basically the only record on what was discussed.  So, it's 
important for you to check out that they match you think was said at 
the meeting.  Please give them a quick look!

Comments can be sent off-list, or if you deem them important enough, 
on-list.

(hat off)

-- 
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 owner-v6ops@ops.ietf.org  Tue Nov 16 15:06:37 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06499
	for <v6ops-archive@lists.ietf.org>; Tue, 16 Nov 2004 15:06:37 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
	id 1CU9ZV-000KZg-Ny
	for v6ops-data@psg.com; Tue, 16 Nov 2004 20:05:01 +0000
Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk)
	by psg.com with esmtp (Exim 4.43 (FreeBSD))
	id 1CU9ZU-000KYz-Fc
	for v6ops@ops.ietf.org; Tue, 16 Nov 2004 20:05:00 +0000
Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131])
	by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id iAGK4xGn018708
	for <v6ops@ops.ietf.org>; Tue, 16 Nov 2004 20:04:59 GMT
Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162])
	by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id UAA05058
	for <v6ops@ops.ietf.org>; Tue, 16 Nov 2004 20:04:56 GMT
Received: (from tjc@localhost)
	by login.ecs.soton.ac.uk (8.11.6/8.11.6) id iAGK4uA07104
	for v6ops@ops.ietf.org; Tue, 16 Nov 2004 20:04:56 GMT
Date: Tue, 16 Nov 2004 20:04:56 +0000
From: Tim Chown <tjc@ecs.soton.ac.uk>
To: "'v6ops@ops.ietf.org '" <v6ops@ops.ietf.org>
Subject: Re: proposed new v6ops charter
Message-ID: <20041116200456.GV4961@login.ecs.soton.ac.uk>
Mail-Followup-To: "'v6ops@ops.ietf.org '" <v6ops@ops.ietf.org>
References: <Pine.LNX.4.61.0411121536190.19151@netcore.fi> <BC8CDA16-378F-11D9-9C01-00039358A080@sun.com> <Pine.LNX.4.61.0411160933400.4177@netcore.fi>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.61.0411160933400.4177@netcore.fi>
User-Agent: Mutt/1.4i
X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information
X-ECS-MailScanner: Found to be clean
X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham 
	version=3.0.1
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

On Tue, Nov 16, 2004 at 09:54:22AM +0200, Pekka Savola wrote:
> 
> Do you have further examples in mind to talk about here?  IMHO, it's 
> good to have examples, and I didn't remove them (even if they were 
> done) because they were illustrating which kind of issues the charter 
> was referring to.

I would agree to keep examples.   maybe you could cite things like multicast
with transition.   we should hint that external wg specific items will be
distilled to those wgs (dnsop, mboned, etc).
 
> Agreed, though the item 2 has slightly different focus as I read it. 
> It seems to say, "check and keep checking the existing IPv6 
> specifications that they work OK", while item 1 seems to say "identify 
> missing pieces which need new work".

I would assume our main feedback is to ipv6 wg, but how much longer do we
see the ipv6 wg existing? :)
 
> True, if item 1 is made generic -- there is a danger in too much 
> genericity that one forgets which specific kinds of tasks (like 2 and 
> 4 here) have been put forward to the WG.

I see 1 as a general statement of intent, with 4 being a specific example.
 
> >I thought we were done with that.
> 
> What do you call the campus transition document then?  Granted the 
> text in the second paragraph should be tweaked a bit to fit.

I agree with Pekka on this one.
 
> Another related document was the description of broadband ISP IPv6 
> deployment efforts.

Yes, that was good and useful.
 
> >To up-level this discussion, my feedback to the chairs and the AD is 
> >that v6ops should focus more on ops issues. The target of this wg 
> >should be to document in RFCs issues that came during deployment 
> >with suggested workaround and/or send draft in the relevant wg when 
> >something need to be changed in protocol specs.
> 
> "Issues that come during deployment" can be interpreted either widely 
> or narrowly.   And depending on that..

True, but I think that is a focus, and thus should be what point 1 says,
which actually it rather does :)

> If we project the draft charter you'd like to see to documents 
> produced by this WG, or proposed to this WG, as concrete examples, 
> which do you should have been or be in scope:

Good question.  Most of them.  MIP scenarios should be pushed to mip6
perhaps (or a miptrans BoF), and distributed security certainly to the
security area (as a BoF in IETF62), as should tschofenig's draft, I think.

The rest should be v6ops wg at present, as they are operational without
specific applicability to other WGs (though line items may come out of
them for other WGs, e.g. IPv6 WG for perhaps some renumbering support
requirements).

-- 
Tim



From owner-v6ops@ops.ietf.org  Tue Nov 16 15:07:38 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06616
	for <v6ops-archive@lists.ietf.org>; Tue, 16 Nov 2004 15:07:37 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
	id 1CU9bq-000Ku3-Rc
	for v6ops-data@psg.com; Tue, 16 Nov 2004 20:07:26 +0000
Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk)
	by psg.com with esmtp (Exim 4.43 (FreeBSD))
	id 1CU9bp-000Ktk-OQ
	for v6ops@ops.ietf.org; Tue, 16 Nov 2004 20:07:26 +0000
Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131])
	by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id iAGK7OGn018770
	for <v6ops@ops.ietf.org>; Tue, 16 Nov 2004 20:07:24 GMT
Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162])
	by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id UAA05207
	for <v6ops@ops.ietf.org>; Tue, 16 Nov 2004 20:07:20 GMT
Received: (from tjc@localhost)
	by login.ecs.soton.ac.uk (8.11.6/8.11.6) id iAGK7Kr07149
	for v6ops@ops.ietf.org; Tue, 16 Nov 2004 20:07:20 GMT
Date: Tue, 16 Nov 2004 20:07:19 +0000
From: Tim Chown <tjc@ecs.soton.ac.uk>
To: v6ops@ops.ietf.org
Subject: Re: proposed new v6ops charter
Message-ID: <20041116200719.GW4961@login.ecs.soton.ac.uk>
Mail-Followup-To: v6ops@ops.ietf.org
References: <BDBED72A.50199%jordi.palet@consulintel.es> <AA4EB3F0-37A7-11D9-818C-000A95928574@kurtis.pp.se>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <AA4EB3F0-37A7-11D9-818C-000A95928574@kurtis.pp.se>
User-Agent: Mutt/1.4i
X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information
X-ECS-MailScanner: Found to be clean
X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham 
	version=3.0.1
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

On Tue, Nov 16, 2004 at 09:15:24AM +0100, Kurt Erik Lindqvist wrote:
> 
> If a certain area in the IETF is overloaded or unaware of IPv6, then 
> THOSE are the problems we need to address. Not pushing ahead at any 
> cost somewhere else.

I agree with this if it's a specific issue that is applicable to another
area WG.  There is a point to which something should be pushed before its
lack of uptake should be taken as a hint... :)

Tim



From owner-v6ops@ops.ietf.org  Tue Nov 16 20:01:40 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17954
	for <v6ops-archive@lists.ietf.org>; Tue, 16 Nov 2004 20:01:40 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
	id 1CUEAb-000Ouz-3k
	for v6ops-data@psg.com; Wed, 17 Nov 2004 00:59:37 +0000
Received: from [159.226.39.7] (helo=ict.ac.cn)
	by psg.com with smtp (Exim 4.43 (FreeBSD))
	id 1CUEAZ-000Ouc-Dj
	for v6ops@ops.ietf.org; Wed, 17 Nov 2004 00:59:36 +0000
Received: (qmail 16097 invoked by uid 507); 17 Nov 2004 00:29:10 -0000
Received: from unknown (HELO ThinkPadX31) (liumin@159.226.39.104)
  by ict.ac.cn with SMTP; 17 Nov 2004 00:29:10 -0000
From: "Liu Min" <liumin@ict.ac.cn>
To: <v6ops@ops.ietf.org>, <v6tc@ietf.org>
Subject: FW: I-D ACTION:draft-liumin-v6ops-silkroad-02.txt
Date: Wed, 17 Nov 2004 08:59:31 +0800
Message-ID: <00cd01c4cc40$b270b2c0$4b74a8c0@ThinkPadX31>
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_00CE_01C4CC83.C093F2C0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham 
	version=3.0.1
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_00CE_01C4CC83.C093F2C0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi:
There is a new version of the draft silkroad.

Compared with the previous version, there are the main changes:

1.  Change the model of Silkroad. SN (silkroad navigator) will not =
receive
SC (silkroad client)'s request by http, and will not assign SAR =
(silkroad
access router) for SC. There will be no direct interaction between SC =
and
SN.

2.  The authentication and coherence for SARs and SNs in one ISP will =
follow
the specific ISP's security and route consideration and existing =
mechanisms.
There will be no automatic synchronization and interaction between SARs =
and
SNs belonging to different ISPs, unless there are prior agreements.
Generally, the packet forwarding between SARs belonging to different =
ISPs
will follow IPv6 rules and no route optimization could be made. =20

3.  Explicitly indicate that SN is recommended for ISP whose SARs are
relatively few. However, it is mandatory for ISP who has many SARs and =
SCs.
There may be hierarchical SNs for one ISP.=20

4.  Explicitly indicate that Silkroad is one mechanism to be used by the =
ISP
to provide a managed tunnel work through NATs to its customers.

5.  Remove the component in the protocol for requesting an arbitrary =
length.
The default prefix length will be a /64. Whether providing an arbitrary
length prefix will be up to the specific ISP's policy and business =
process.
The ISP may require prior agreement for special requirements.

6.  Remove Control Option type to determine the transmission method =
between
SARs and leave the choice to ISP.

7.  Change the transmission process between SC and regular node in 4.2.4 =
and
4.2.5 change all the figures in this draft.=20

8.  Add the consideration of mobility support in 7.3.

9.  Move the comparison with Teredo to Appendix A and add the comparison
with tunnel broker solutions.

10. Indicate that route optimization is optional and ISPs could decide
whether to support route optimization for their Silkroad clients. =
Generally,
route optimization will only be done between SCs belonging to the same =
ISP,
unless there are prior agreements between different ISPs.
  =20
Any comments will be appreciated.

=20
Best Wishes,
=20

Liu Min
=20
Institute of Computing Technology
Chinese Academy of Sciences
Tel: (86-10) 6256 5533-9240=20
E-mail: liumin@ict.ac.cn


-----Original Message-----
From: i-d-announce-bounces@ietf.org =
[mailto:i-d-announce-bounces@ietf.org]
On Behalf Of Internet-Drafts@ietf.org
Sent: Wednesday, November 17, 2004 5:13 AM
To: i-d-announce@ietf.org
Subject: I-D ACTION:draft-liumin-v6ops-silkroad-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.


	Title		: Tunneling IPv6 with private IPv4 addresses=20
                          behind NAT devices
	Author(s)	: L. Min, et al.
	Filename	: draft-liumin-v6ops-silkroad-02.txt
	Pages		: 24
	Date		: 2004-11-16
=09
The growth of IPv6 networks started mainly using the transport =
facilities
offered by the current Internet. This led to the development of several
techniques to manage IPv6 over IPv4 tunnels. However, classic tunneling
methods do not work when the IPv6 candidate node is isolated behind a
Network Address Translator (NAT)   device. We propose here a service, =
called
Silkroad, to enable nodes located behind one or several IPv4 NATs to =
obtain
IPv6 connectivity. It can provide IPv6 connectivity through all existing =
NAT
types and does not require any update of them. In addition, Silkroad =
could
provide managed IPv6 prefixes with path optimized routing directly =
between
clients.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-liumin-v6ops-silkroad-02.txt

To remove yourself from the I-D Announcement list, send a message to=20
i-d-announce-request@ietf.org with the word unsubscribe in the body of =
the
message. =20
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the =
username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-liumin-v6ops-silkroad-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html=20
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-liumin-v6ops-silkroad-02.txt".
=09
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
	=09
	=09
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

------=_NextPart_000_00CE_01C4CC83.C093F2C0
Content-Type: Message/External-body;
	name="ATT00120.dat"
Content-Disposition: attachment;
	filename="ATT00120.dat"
Content-Transfer-Encoding: 7bit

Content-Type: text/plain
Content-ID: <2004-11-16113036.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-liumin-v6ops-silkroad-02.txt

------=_NextPart_000_00CE_01C4CC83.C093F2C0
Content-Type: Message/External-body;
	name="draft-liumin-v6ops-silkroad-02.txt"
Content-Disposition: attachment;
	filename="draft-liumin-v6ops-silkroad-02.txt"
Content-Transfer-Encoding: 7bit

Content-Type: text/plain
Content-ID: <2004-11-16113036.I-D@ietf.org>


------=_NextPart_000_00CE_01C4CC83.C093F2C0
Content-Type: text/plain;
	name="ATT00123.txt"
Content-Disposition: attachment;
	filename="ATT00123.txt"
Content-Transfer-Encoding: 7bit

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www1.ietf.org/mailman/listinfo/i-d-announce

------=_NextPart_000_00CE_01C4CC83.C093F2C0--





From owner-v6ops@ops.ietf.org  Wed Nov 17 00:50:05 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13372
	for <v6ops-archive@lists.ietf.org>; Wed, 17 Nov 2004 00:50:05 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
	id 1CUIdR-000144-22
	for v6ops-data@psg.com; Wed, 17 Nov 2004 05:45:41 +0000
Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com)
	by psg.com with esmtp (Exim 4.43 (FreeBSD))
	id 1CUIdP-00013q-Jc
	for v6ops@ops.ietf.org; Wed, 17 Nov 2004 05:45:39 +0000
Received: from esunmail ([129.147.156.34])
	by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id iAH5jcui009562
	for <v6ops@ops.ietf.org>; Tue, 16 Nov 2004 22:45:39 -0700 (MST)
Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM
 (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004))
 with ESMTP id <0I7B00FJA6O1YG@edgemail1.Central.Sun.COM> for
 v6ops@ops.ietf.org; Tue, 16 Nov 2004 22:45:38 -0700 (MST)
Received: from [192.168.1.2] ([66.93.39.75])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004))
 with ESMTPSA id <0I7B00DQO6O0HH@mail.sun.net> for v6ops@ops.ietf.org; Tue,
 16 Nov 2004 22:45:37 -0700 (MST)
Date: Tue, 16 Nov 2004 21:45:34 -0800
From: Alain Durand <Alain.Durand@Sun.COM>
Subject: Re: proposed new v6ops charter
In-reply-to: <Pine.LNX.4.61.0411160933400.4177@netcore.fi>
To: Pekka Savola <pekkas@netcore.fi>
Cc: "'v6ops@ops.ietf.org '" <v6ops@ops.ietf.org>,
        "'Soininen Jonne '" <jonne.soininen@nokia.com>,
        David Kessens <david@iprg.nokia.com>
Message-id: <E6BE5980-385B-11D9-85A3-00039376A6AA@sun.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.619)
Content-type: text/plain; charset=US-ASCII; format=flowed
Content-transfer-encoding: 7BIT
References: <Pine.LNX.4.61.0411121536190.19151@netcore.fi>
 <BC8CDA16-378F-11D9-9C01-00039358A080@sun.com>
 <Pine.LNX.4.61.0411160933400.4177@netcore.fi>
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham 
	version=3.0.1
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7BIT


On Nov 15, 2004, at 11:54 PM, Pekka Savola wrote:

> On Mon, 15 Nov 2004, Alain Durand wrote:
>>>   For example, important pieces of the Internet infrastructure
>>>   such as DNS, SMTP and SIP have specific
>>> operational issues when
>>>   they operate in a shared IPv4/IPv6 network. The v6ops WG will
>>>   cooperate with the relevant areas and WGs to document those
>>>   issues, and find protocol or operational solutions to those
>>>   problems.
>>
>> DNS IPv6 issues are well handled by DNSop, my understanding was
>> that one of the SIP wg is eventually talking about v4/v6 coexistence
>> and I'm not sure anymore about the fate of v6 SMTP.
>>
>> My point is that those examples should be removed as they are NOT 
>> being
>> addressed by the v6OPS wg, neither in the recent past nor in the 
>> proposed
>> milestones.
>
> Do you have further examples in mind to talk about here?  IMHO, it's 
> good to have examples, and I didn't remove them (even if they were 
> done) because they were illustrating which kind of issues the charter 
> was referring to.

The experience has proven that such specific items are better covered 
where the clues are,
i.e. in the relevant wg and not in v6ops. Participation to those wgs by 
v6ops members is more likely
to get the work done (by exporting v6 clues outside of v6ops) as oppose 
to try to do
everything in v6ops.

>> Again, this could be folded in 1).
>
> True, if item 1 is made generic -- there is a danger in too much 
> genericity that one forgets which specific kinds of tasks (like 2 and 
> 4 here) have been put forward to the WG.

I do not see anything really more specific in the suggested charter 
either.
Saying you want to work in the "security" or "Ipv6 protocol" isn't 
helping much.
This is the dilemma with an Ops group working on deploying a new 
technology,
work is relevant when specific issues are discovered while deploying, 
but such
issues are unpredictable, thus difficult to put in a charter.

>>> 5. Publish Informational or BCP RFCs that identify and analyze 
>>> solutions
>>>   for deploying IPv6 within common network environments, such as
>>>   ISP Networks (including Core, HFC/Cable, DSL & Dial-up networks),
>>>   Enterprise Networks, Unmanaged Networks (Home/Small Office), and
>>>   Cellular Networks.
>>>   These documents should serve as useful guides to network
>>>   operators and users on how to deploy IPv6 within their existing
>>>   IPv4 networks, as well as in new network installations.
>>
>> I thought we were done with that.
>
> What do you call the campus transition document then?  Granted the 
> text in the second paragraph should be tweaked a bit to fit.

I do not like much the idea of analyzing generic solutions in generic 
environment,
this is a bit like telling people how to run their network. I'd rather 
like to see
things like "deployment reports", explaining what has been found to 
work and what not.
I think the campus document is much closer to that in its spirit than
guiding "network operators and users on how to deploy IPv6 within their 
existing IPv4 networks"

> Another related document was the description of broadband ISP IPv6 
> deployment efforts.
>
> It's not like we want to do a lot more of the scenarios documents, and 
> we certainly don't want to go down the analysis path, but if someone 
> wants to do a document describing IPv6 deployment scenario, is there a 
> good reason to rule it out?

If someone want to explain meaningful environments where the current 
toolbox does nor work well, sure.
However if this is about stalling other meaningful work, or going into 
endless ratholes, I'm not sure it's worth the pain.

>> I do not see any milestones about the work on v6onbydefault, arguably 
>> the few pieces of real ops feedback that was worked on in this wg 
>> along DNS issues.
>
> The v6onbydefault work is close to done and going forward as it is so 
> there is no need to call it out here, AFAICS.

Maybe there could be another discussion on how to get this one out of 
the current deadlock.

> If you refer to some other potential work items relating or close to 
> "v6onbydefault", feel free to suggest them.  I'd expect those are just 
> ones that will come up when folks think of something.

Precisely. And this is what the charter should specifically mention as 
potential wg work items.
About specific examples, the "don't publish unreachable" draft may be 
resurrected in DNSops
and there is significant overlap with v6onbydefault. This is a 
cross-area that needs more work.

>> To up-level this discussion, my feedback to the chairs and the AD is 
>> that v6ops should focus more on ops issues. The target of this wg 
>> should be to document in RFCs issues that came during deployment with 
>> suggested workaround and/or send draft in the relevant wg when 
>> something need to be changed in protocol specs.
>
> "Issues that come during deployment" can be interpreted either widely 
> or narrowly.   And depending on that..

The exact wording to make it clearer is left as an exercise for the 
chairs and AD ;-)

> To keep this practical, do you think some of those proposed 
> deliverables explicitly mentioned in the draft charter would be 
> inappropriate for the scope of this WG?

No.  However, most of them are left-overs from the previous incarnation 
of v6ops.

>
> If we project the draft charter you'd like to see to documents 
> produced by this WG, or proposed to this WG, as concrete examples, 
> which do you should have been or be in scope:
>  - draft-ietf-v6ops-renumbering-procedure
>  - draft-ietf-v6ops-6to4-security
>  - draft-ietf-v6ops-application-transition
>  - the scenarios documents we did
>  - the analysis documents we did
>  - draft-chown-v6ops-campus-transition
>  - draft-larsson-v6ops-mip-scenarios
>  - draft-asadullah-v6ops-bb-deployment-scenarios
>  - draft-ietf-v6ops-v6onbydefault
>  - draft-ietf-v6ops-mech-v2
>  - draft-aoun-v6ops-natpt-deprecate
>  - draft-chown-v6ops-port-scanning-implications
>  - draft-chown-v6ops-renumber-thinkabout
>  - draft-chown-v6ops-vlan-usage
>  - draft-savola-v6ops-security-overview
>  - draft-vandevelde-v6ops-nap
>  - draft-tschofenig-v6ops-secure-tunnels
>  - Jordi et al's distributed security work
>
> Let's not talk too vaguely because then nobody can understand what 
> each other is saying, because "let's do operational stuff" is a very 
> generic statement :)
>
> I think I hear loud and clear that you want to see documents like 
> campus transition, e.g., describing how the transition mechanisms work 
> or don't, and issues brought up relating to deployment, e.g., as was 
> done in v6onbydefault.  I think the current draft charter is open to 
> those.  But what else would you feel would be OK?  Note that if those 
> would be the only kind of work to be done, the proposed deliverables 
> list might look close to empty.

let's be specific, however, this is not the best place to discuss the 
fate of specific drafts.
The security & renumbering docs are clearly Ops issue, so is vlan usage.
Deprecating NAT-PT will be, has it has been shown to be a operational 
problem.
The campus & broadband docs are good "feedback, how-to" docs useful in 
an Ops context.
The apps doc is done, no need to talk about it
IMHO, mech-v2 would certainly be better off if it was transfered to the 
ipv6 wg... the pace of progress
is just amazingly slow.
And about the scenarios/analysis, I was under the impression that the 
work was over.

But, in a sense, all the above are legacy work items, and in most 
cases, in fairly advance stages.
I'm more concerned about new work items.

The two directions that require attention seems to be Mobility and 
v6-only networks.

There have been several mobility experiments with v4 & v6 networks, I 
remember for example
a draft from Carl Williams reporting results. Certainly more is needed 
in that area without necessarily
going through the deadly scenario/analysis/paralysis route.

The other area that require attention is IPv6 only networks, that 
involved translation and/or
IPv6 over IPv4 tunneling. This is the case that for many years many 
have considered as an
end game scenario, but apparently, it seems that such networks are 
being deployed today.
Again, operational feedback to root goals/requirements for potentially 
missing tools
are needed.

Do you think the proposed charter covers those two directions in an 
adequate manner?

	- Alain.




From owner-v6ops@ops.ietf.org  Wed Nov 17 06:16:51 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13629
	for <v6ops-archive@lists.ietf.org>; Wed, 17 Nov 2004 06:16:50 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
	id 1CUNlj-0007NZ-Lh
	for v6ops-data@psg.com; Wed, 17 Nov 2004 11:14:35 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.43 (FreeBSD))
	id 1CUNlh-0007NI-LK
	for v6ops@ops.ietf.org; Wed, 17 Nov 2004 11:14:34 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id iAHBEUA13464;
	Wed, 17 Nov 2004 13:14:30 +0200
Date: Wed, 17 Nov 2004 13:14:30 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: Alain Durand <Alain.Durand@Sun.COM>
cc: "'v6ops@ops.ietf.org '" <v6ops@ops.ietf.org>,
        "'Soininen Jonne '" <jonne.soininen@nokia.com>,
        David Kessens <david@iprg.nokia.com>
Subject: Re: proposed new v6ops charter
Message-ID: <Pine.LNX.4.61.0411171255560.11592@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham 
	version=3.0.1
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

On Tue, 16 Nov 2004, Alain Durand wrote:
>> Do you have further examples in mind to talk about here?  IMHO, it's
>> good to have examples, and I didn't remove them (even if they were
>> done) because they were illustrating which kind of issues the charter
>> was referring to.
>
> The experience has proven that such specific items are better 
> covered where the clues are, i.e. in the relevant wg and not in 
> v6ops. Participation to those wgs by v6ops members is more likely to 
> get the work done (by exporting v6 clues outside of v6ops) as oppose 
> to try to do everything in v6ops.

Totally agree here of course.  The problem is most felt, however, in 
cases where the WG in charge or that particular technology (e.g., 
SMTP) has been closed ages ago, and possibly even the mailing list has 
been killed.

But again, do you have examples to put here?  Either of the cases 
where this work should be done elsewhere (possibly with assitance from 
v6ops), or where this could be done here?

>> What do you call the campus transition document then?  Granted the
>> text in the second paragraph should be tweaked a bit to fit.
>
> I do not like much the idea of analyzing generic solutions in 
> generic environment, this is a bit like telling people how to run 
> their network.  I'd rather like to see things like "deployment 
> reports", explaining what has been found to work and what not. I 
> think the campus document is much closer to that in its spirit than 
> guiding "network operators and users on how to deploy IPv6 within 
> their existing IPv4 networks"

I personally see little harm in creating a document which folks could 
read for guidance.  It's not a mandate, of course, but better than 
nothing. Is it useful to put out 5 documents instead of just one (one 
for different flavours of BB ISP deployment)?  I see no reason to make 
hard and fast decisions on this one way or the other.  Both kind of 
documents may be useful. (Though I'm not 100% certain how useful it is 
to publish, as RFCs, too specific documents.)

>> The v6onbydefault work is close to done and going forward as it is so
>> there is no need to call it out here, AFAICS.
>
> Maybe there could be another discussion on how to get this one out of
> the current deadlock.

Yes.  I'll open a separate thread on this.

>> If you refer to some other potential work items relating or close to
>> "v6onbydefault", feel free to suggest them.  I'd expect those are just
>> ones that will come up when folks think of something.
>
> Precisely. And this is what the charter should specifically mention 
> as potential wg work items.

In the charter itself or suggested deliverables?

Suggest text? :-)

> About specific examples, the "don't 
> publish unreachable" draft may be resurrected in DNSops and there is 
> significant overlap with v6onbydefault. This is a cross-area that 
> needs more work.

This seems a clear DNSOP thing which v6ops should not get entangled 
in, except for making sure folks here will make their voices heard in 
dnsop about the draft's relation to IPv6 addresses.

>> "Issues that come during deployment" can be interpreted either widely
>> or narrowly.   And depending on that..
>
> The exact wording to make it clearer is left as an exercise for the
> chairs and AD ;-)

That's likely the only way to do that.  Some seem uncomfortable with 
that, though, because they see v6ops charter as potentially being 
receptive to Foo..

>> To keep this practical, do you think some of those proposed
>> deliverables explicitly mentioned in the draft charter would be
>> inappropriate for the scope of this WG?
>
> No.  However, most of them are left-overs from the previous incarnation
> of v6ops.

Sure, I was just asking you to apply the policy you proposed to the 
previous drafts as a thought exercise which ones would be up for 
adoption if those hadn't been published and we had the policy you've 
in mind in place.

In a way, I tried to use this tool to get some concrete idea what kind 
of policy you had in mind.  Apparently you also had a "wide" 
interpretation of operational topics, so we're on the same page.

> IMHO, mech-v2 would certainly be better off if it was transfered to 
> the ipv6 wg... the pace of progress is just amazingly slow.

Well, its past IESG evals already, and now David Kessens just needs to 
make a decision how to interpret one Steve Bellovin's comment..

> There have been several mobility experiments with v4 & v6 networks, 
> I remember for example a draft from Carl Williams reporting results. 
> Certainly more is needed in that area without necessarily going 
> through the deadly scenario/analysis/paralysis route.

Not sure how useful it is to report such specific results as RFCs.  It 
seems there are many considerations about mobility here, which are 
best answered outside of v6ops with sufficient mobility experience, 
e..g, the miptrans list and a potential BoF.

> The other area that require attention is IPv6 only networks, that 
> involved translation and/or IPv6 over IPv4 tunneling. This is the 
> case that for many years many have considered as an end game 
> scenario, but apparently, it seems that such networks are being 
> deployed today. Again, operational feedback to root 
> goals/requirements for potentially missing tools are needed.

It would certainly be useful to get input from users which want to be 
designing v6-only networks why they want to do it, what issues they've 
faced, etc., but I'm not sure if there has been any of that..

> Do you think the proposed charter covers those two directions in an 
> adequate manner?

It's generic enough to include both, and this seems to be good enough 
for me at least...  We can't hope to enumerate all the potential items 
in the charter..  If you think something should be spelled out, you 
can always suggest text.

-- 
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 owner-v6ops@ops.ietf.org  Wed Nov 17 09:25:42 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02390
	for <v6ops-archive@lists.ietf.org>; Wed, 17 Nov 2004 09:25:42 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
	id 1CUQht-0001e6-Pq
	for v6ops-data@psg.com; Wed, 17 Nov 2004 14:22:49 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.43 (FreeBSD))
	id 1CUQhp-0001dU-HD
	for v6ops@ops.ietf.org; Wed, 17 Nov 2004 14:22:46 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id iAHEMhd18099
	for <v6ops@ops.ietf.org>; Wed, 17 Nov 2004 16:22:43 +0200
Date: Wed, 17 Nov 2004 16:22:43 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: v6ops@ops.ietf.org
Subject: Situation with draft-ietf-v6ops-v6onbydefault-03.txt
Message-ID: <Pine.LNX.4.61.0411171605220.17649@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.0.1
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

Hi,

Alain wanted to raise the issue on what's up with 
draft-ietf-v6ops-v6onbydefault-03.txt.

At the IESG evaluation, two people raised a particular significant 
concern: the document should not be discussing solutions to these 
problems, if the solution has not been advanced in the appropriate WGs 
or other fora.  (It would be OK to just write about the problems, 
however.)

These seem to be two ways forward here:

  1) make sure work on the solutions is moving forward in the 
appropriate WGs, etc., and wait until publishing this document, with 
mentioning the solutions.  Drawback is that it may take long time to 
get these merged in the specification efforts.

  2) remove all the references to solutions in this document (I believe 
most of this was already done in -03 revision).  Drawback is that the 
document is much less useful as it is, and we still need to make sure 
these things actually get fixed.  Just describing problems doesn't 
really help all that much unless they're also fixed...

I've personally favoured 1).

Are there opinions on the approach?

For what it's worth, the status wrt solutions is as follows:
  - draft-gont-tcpm-tcp-soft-errors-01.txt (presented twice at TCPM WG 
meetings) describes the "soft error" behaviour, and is being actively 
debated at TCPM WG right now.  Generally, these has been positive 
reaction, except from a particular TCP purist (or two)  who seem to be 
resisting very strongly making any TCP modifications and instead 
advocating changing all the applications, etc., and requiring all 
kinds of evidence that this fix does not have ill effects.

  - this has been raportedly integrated with SCTP spec (by the SCTP 
authors) as well (I haven't checked), and mentioned to DCCP people. 
I haven't checked whether newest DCCP specs conform to this behaviour.

  - the onlink assumption is dependent on rfc2461bis (which is OK now) 
which is now at WGLC.

  - no work has been done on RFC3484 rule wrt. "unreachable 
destination", but this didn't seem needed as the removal of onlink 
assumption and ICMP soft errors should do the job.  Should there be 
some?

  - the VPN problem is an implementation issue; has it been reported to 
the vendor?  Is there a PR or some other identification tag for it?

  - the application transition document is already done so application 
robustness is OK.

So, in summary, it seems all of this is in a relatively good swing, 
except for the TCP modification which is facing some resistance. 
Unfortunately, that is probably the most important fix that should go 
in...

-- 
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 owner-v6ops@ops.ietf.org  Wed Nov 17 15:08:31 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06948
	for <v6ops-archive@lists.ietf.org>; Wed, 17 Nov 2004 15:08:30 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
	id 1CUW4L-000Bh6-JM
	for v6ops-data@psg.com; Wed, 17 Nov 2004 20:06:21 +0000
Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk)
	by psg.com with esmtp (Exim 4.43 (FreeBSD))
	id 1CUW4K-000Bgr-DW
	for v6ops@ops.ietf.org; Wed, 17 Nov 2004 20:06:20 +0000
Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131])
	by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id iAHK6JGn026154
	for <v6ops@ops.ietf.org>; Wed, 17 Nov 2004 20:06:19 GMT
Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162])
	by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id UAA27150
	for <v6ops@ops.ietf.org>; Wed, 17 Nov 2004 20:06:17 GMT
Received: (from tjc@localhost)
	by login.ecs.soton.ac.uk (8.11.6/8.11.6) id iAHK6HM03099
	for v6ops@ops.ietf.org; Wed, 17 Nov 2004 20:06:17 GMT
Date: Wed, 17 Nov 2004 20:06:17 +0000
From: Tim Chown <tjc@ecs.soton.ac.uk>
To: v6ops@ops.ietf.org
Subject: App aspects?
Message-ID: <20041117200616.GB3006@login.ecs.soton.ac.uk>
Mail-Followup-To: v6ops@ops.ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4i
X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information
X-ECS-MailScanner: Found to be clean
X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham 
	version=3.0.1
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

Hi,

What came of draft-ietf-v6ops-application-transition-03?

Seems to have gone to IESG but got stuck?   Just curious as it's a very
useful document.

-- 
Tim





From owner-v6ops@ops.ietf.org  Wed Nov 17 15:52:13 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11137
	for <v6ops-archive@lists.ietf.org>; Wed, 17 Nov 2004 15:52:12 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
	id 1CUWmD-000Fwe-Mu
	for v6ops-data@psg.com; Wed, 17 Nov 2004 20:51:41 +0000
Received: from [129.6.16.226] (helo=smtp.nist.gov)
	by psg.com with esmtp (Exim 4.43 (FreeBSD))
	id 1CUWmC-000FwJ-8m
	for v6ops@ops.ietf.org; Wed, 17 Nov 2004 20:51:40 +0000
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93])
	by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id iAHKp82x008321;
	Wed, 17 Nov 2004 15:51:08 -0500
Received: from nist.gov (itg-03.antd.nist.gov [129.6.50.182])
	by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id iAHKocYB008548;
	Wed, 17 Nov 2004 15:50:38 -0500 (EST)
Message-ID: <419BB99E.E2DD5E88@nist.gov>
Date: Wed, 17 Nov 2004 15:50:38 -0500
From: "M-K. Shin" <mshin@nist.gov>
Organization: ETRI/NIST
X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U)
X-Accept-Language: en,ko
MIME-Version: 1.0
To: Tim Chown <tjc@ecs.soton.ac.uk>
CC: v6ops@ops.ietf.org
Subject: Re: App aspects?
References: <20041117200616.GB3006@login.ecs.soton.ac.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: mshin@nist.gov
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham 
	version=3.0.1
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

In State: RFC Ed Queue

See - http://www.rfc-editor.org/queue.html

Thanks,
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Myung-Ki Shin, Ph.D.| mshin@nist.gov
ETRI/NIST           | 820 West Diamond Avenue
                    | Gaithersburg, MD 20899


Tim Chown wrote:

> Hi,
>
> What came of draft-ietf-v6ops-application-transition-03?
>
> Seems to have gone to IESG but got stuck?   Just curious as it's a very
> useful document.
>
> --
> Tim





From owner-v6ops@ops.ietf.org  Thu Nov 18 07:44:53 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20370
	for <v6ops-archive@lists.ietf.org>; Thu, 18 Nov 2004 07:44:53 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
	id 1CUlb0-000COI-Bv
	for v6ops-data@psg.com; Thu, 18 Nov 2004 12:41:06 +0000
Received: from [195.30.1.100] (helo=moebius2.Space.Net)
	by psg.com with smtp (Exim 4.43 (FreeBSD))
	id 1CUlaG-000CGr-DG
	for v6ops@ops.ietf.org; Thu, 18 Nov 2004 12:40:21 +0000
Received: (qmail 55292 invoked by uid 1007); 18 Nov 2004 12:39:52 -0000
MBOX-Line: From owner-v6ops@ops.ietf.org Wed Nov 17 11:25:34 2004
DomainKey-Status: no signature
Date: Wed, 17 Nov 2004 13:14:30 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: Alain Durand <Alain.Durand@Sun.COM>
cc: "'v6ops@ops.ietf.org '" <v6ops@ops.ietf.org>,
        "'Soininen Jonne '" <jonne.soininen@nokia.com>,
        David Kessens <david@iprg.nokia.com>
Subject: Re: proposed new v6ops charter
Message-ID: <Pine.LNX.4.61.0411171255560.11592@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Lines: 134
X-Loop: mailbounceto 1.0
Status: RO
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,DATE_IN_PAST_24_48 
	autolearn=no version=3.0.1
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

On Tue, 16 Nov 2004, Alain Durand wrote:
>> Do you have further examples in mind to talk about here?  IMHO, it's
>> good to have examples, and I didn't remove them (even if they were
>> done) because they were illustrating which kind of issues the charter
>> was referring to.
>
> The experience has proven that such specific items are better 
> covered where the clues are, i.e. in the relevant wg and not in 
> v6ops. Participation to those wgs by v6ops members is more likely to 
> get the work done (by exporting v6 clues outside of v6ops) as oppose 
> to try to do everything in v6ops.

Totally agree here of course.  The problem is most felt, however, in 
cases where the WG in charge or that particular technology (e.g., 
SMTP) has been closed ages ago, and possibly even the mailing list has 
been killed.

But again, do you have examples to put here?  Either of the cases 
where this work should be done elsewhere (possibly with assitance from 
v6ops), or where this could be done here?

>> What do you call the campus transition document then?  Granted the
>> text in the second paragraph should be tweaked a bit to fit.
>
> I do not like much the idea of analyzing generic solutions in 
> generic environment, this is a bit like telling people how to run 
> their network.  I'd rather like to see things like "deployment 
> reports", explaining what has been found to work and what not. I 
> think the campus document is much closer to that in its spirit than 
> guiding "network operators and users on how to deploy IPv6 within 
> their existing IPv4 networks"

I personally see little harm in creating a document which folks could 
read for guidance.  It's not a mandate, of course, but better than 
nothing. Is it useful to put out 5 documents instead of just one (one 
for different flavours of BB ISP deployment)?  I see no reason to make 
hard and fast decisions on this one way or the other.  Both kind of 
documents may be useful. (Though I'm not 100% certain how useful it is 
to publish, as RFCs, too specific documents.)

>> The v6onbydefault work is close to done and going forward as it is so
>> there is no need to call it out here, AFAICS.
>
> Maybe there could be another discussion on how to get this one out of
> the current deadlock.

Yes.  I'll open a separate thread on this.

>> If you refer to some other potential work items relating or close to
>> "v6onbydefault", feel free to suggest them.  I'd expect those are just
>> ones that will come up when folks think of something.
>
> Precisely. And this is what the charter should specifically mention 
> as potential wg work items.

In the charter itself or suggested deliverables?

Suggest text? :-)

> About specific examples, the "don't 
> publish unreachable" draft may be resurrected in DNSops and there is 
> significant overlap with v6onbydefault. This is a cross-area that 
> needs more work.

This seems a clear DNSOP thing which v6ops should not get entangled 
in, except for making sure folks here will make their voices heard in 
dnsop about the draft's relation to IPv6 addresses.

>> "Issues that come during deployment" can be interpreted either widely
>> or narrowly.   And depending on that..
>
> The exact wording to make it clearer is left as an exercise for the
> chairs and AD ;-)

That's likely the only way to do that.  Some seem uncomfortable with 
that, though, because they see v6ops charter as potentially being 
receptive to Foo..

>> To keep this practical, do you think some of those proposed
>> deliverables explicitly mentioned in the draft charter would be
>> inappropriate for the scope of this WG?
>
> No.  However, most of them are left-overs from the previous incarnation
> of v6ops.

Sure, I was just asking you to apply the policy you proposed to the 
previous drafts as a thought exercise which ones would be up for 
adoption if those hadn't been published and we had the policy you've 
in mind in place.

In a way, I tried to use this tool to get some concrete idea what kind 
of policy you had in mind.  Apparently you also had a "wide" 
interpretation of operational topics, so we're on the same page.

> IMHO, mech-v2 would certainly be better off if it was transfered to 
> the ipv6 wg... the pace of progress is just amazingly slow.

Well, its past IESG evals already, and now David Kessens just needs to 
make a decision how to interpret one Steve Bellovin's comment..

> There have been several mobility experiments with v4 & v6 networks, 
> I remember for example a draft from Carl Williams reporting results. 
> Certainly more is needed in that area without necessarily going 
> through the deadly scenario/analysis/paralysis route.

Not sure how useful it is to report such specific results as RFCs.  It 
seems there are many considerations about mobility here, which are 
best answered outside of v6ops with sufficient mobility experience, 
e..g, the miptrans list and a potential BoF.

> The other area that require attention is IPv6 only networks, that 
> involved translation and/or IPv6 over IPv4 tunneling. This is the 
> case that for many years many have considered as an end game 
> scenario, but apparently, it seems that such networks are being 
> deployed today. Again, operational feedback to root 
> goals/requirements for potentially missing tools are needed.

It would certainly be useful to get input from users which want to be 
designing v6-only networks why they want to do it, what issues they've 
faced, etc., but I'm not sure if there has been any of that..

> Do you think the proposed charter covers those two directions in an 
> adequate manner?

It's generic enough to include both, and this seems to be good enough 
for me at least...  We can't hope to enumerate all the potential items 
in the charter..  If you think something should be spelled out, you 
can always suggest text.

-- 
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 owner-v6ops@ops.ietf.org  Thu Nov 18 09:38:38 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29002
	for <v6ops-archive@lists.ietf.org>; Thu, 18 Nov 2004 09:38:37 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
	id 1CUnOn-0004v8-Ab
	for v6ops-data@psg.com; Thu, 18 Nov 2004 14:36:37 +0000
Received: from [195.30.1.100] (helo=moebius2.Space.Net)
	by psg.com with smtp (Exim 4.43 (FreeBSD))
	id 1CUnOj-0004uU-4t
	for v6ops@ops.ietf.org; Thu, 18 Nov 2004 14:36:33 +0000
Received: (qmail 63855 invoked by uid 1007); 18 Nov 2004 14:36:32 -0000
Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=testkey; d=space.net;
  b=S5wcFT6U8cVu9GhYSrW3K5QJQjZgOni5kmtSsmiex+N9f4LfRR0tcWwo1HnXsYlw  ;
Date: Thu, 18 Nov 2004 15:36:31 +0100
From: Gert Doering <gert@space.net>
To: Pekka Savola <pekkas@netcore.fi>
Cc: Ciprian Popoviciu <cpopovic@cisco.com>, v6ops@ops.ietf.org,
        Salman Asadullah <sasad@cisco.com>, adeel Ahmed <adahmed@cisco.com>
Subject: Re: ISP IPv6 Deployment Scenarios in Broadband Access
Message-ID: <20041118143631.GY84850@Space.Net>
References: <4.3.2.7.2.20041021152613.0257d200@fruitpie.cisco.com> <Pine.LNX.4.61.0411050830580.3277@netcore.fi>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.61.0411050830580.3277@netcore.fi>
User-Agent: Mutt/1.4.1i
X-NCC-RegID: de.space
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham 
	version=3.0.1
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

Hi,

On Fri, Nov 05, 2004 at 08:42:14AM +0200, Pekka Savola wrote:
> An operator which has deployed bridged-mode DSL ('RBE') said that the 
> only solution for providing bulk v6 access at the moment is requiring 
> the use of DHCPv6 for address assignment (i.e.: because DHCPv4 is 
> snooped for v4, the vendors seem to have implemented the same kind of 
> snooping for v6 w/ DHCPv6).
[..]
>  4) putting all the customers' v6 prefix information in a RADIUS or 
> similar database, so that the advertisement information could be 
> digged up from there.  A lot of work, and does not work automatically. 
> This would also need some glue between bulk config and RADIUS.

How are people envisioning "bulk access with IPv6" anyway?

I'm wondering specifically about the nature of the IPv6 allocations 
- are "operators" planning to do dynamic IPv6 allocations (today you get
a dynamic IPv4 /32, in the future you get a dynamic IPv6 /64)?  

Or are people planning to assign static /48s?

We do the latter, so we need to couple RADIUS and IP(v4/v6) address
management anyway - no big difference here for IPv6 access.  

OTOH, we have no "bulk access with RBE" anyway.   Bulk DSL is done with 
PPPoE/L2TP, which works fine (on Cisco) with IPv6 address pools for
assignment, or static assignments coming from radius.

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  66629  (65398)

SpaceNet AG                 Mail: netmaster@Space.Net
Joseph-Dollinger-Bogen 14   Tel : +49-89-32356-0
80807 Muenchen              Fax : +49-89-32356-299




From owner-v6ops@ops.ietf.org  Thu Nov 18 13:30:11 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19320
	for <v6ops-archive@lists.ietf.org>; Thu, 18 Nov 2004 13:30:10 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
	id 1CUqzy-000HsN-WA
	for v6ops-data@psg.com; Thu, 18 Nov 2004 18:27:14 +0000
Received: from [192.18.98.36] (helo=brmea-mail-4.sun.com)
	by psg.com with esmtp (Exim 4.43 (FreeBSD))
	id 1CUqzx-000Hs9-TY
	for v6ops@ops.ietf.org; Thu, 18 Nov 2004 18:27:14 +0000
Received: from esunmail ([129.147.156.34])
	by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id iAIIRDun009155
	for <v6ops@ops.ietf.org>; Thu, 18 Nov 2004 11:27:13 -0700 (MST)
Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM
 (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004))
 with ESMTP id <0I7E00E6M0LCJN@edgemail1.Central.Sun.COM> for
 v6ops@ops.ietf.org; Thu, 18 Nov 2004 11:27:13 -0700 (MST)
Received: from [192.168.1.2] ([66.93.39.75])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004))
 with ESMTPSA id <0I7E00AZI0KAJZ@mail.sun.net> for v6ops@ops.ietf.org; Thu,
 18 Nov 2004 11:27:13 -0700 (MST)
Date: Thu, 18 Nov 2004 10:27:12 -0800
From: Alain Durand <Alain.Durand@Sun.COM>
Subject: Re: Situation with draft-ietf-v6ops-v6onbydefault-03.txt
In-reply-to: <Pine.LNX.4.61.0411171605220.17649@netcore.fi>
To: Pekka Savola <pekkas@netcore.fi>
Cc: v6ops@ops.ietf.org
Message-id: <76E2D358-398F-11D9-B9DD-00039376A6AA@sun.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.619)
Content-type: text/plain; charset=US-ASCII; format=flowed
Content-transfer-encoding: 7BIT
References: <Pine.LNX.4.61.0411171605220.17649@netcore.fi>
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham 
	version=3.0.1
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7BIT


On Nov 17, 2004, at 6:22 AM, Pekka Savola wrote:

> Hi,
>
> Alain wanted to raise the issue on what's up with 
> draft-ietf-v6ops-v6onbydefault-03.txt.

Thank you for starting this thread. Please note that there is also a 
companion draft,
draft-ietf-v6ops-onlinkassumption-02.txt that provides that rationale 
for the change in
RFC2461 about on-link assumption. What should we do about this draft?
	- publish it as Info RFC to document the rationale for the change in 
the update of RFC2461?
	- same thing, but publish it simultaneously as 2461bis?
	- let it expire has it has served its purpose.

> At the IESG evaluation, two people raised a particular significant 
> concern: the document should not be discussing solutions to these 
> problems, if the solution has not been advanced in the appropriate WGs 
> or other fora.  (It would be OK to just write about the problems, 
> however.)
>
> These seem to be two ways forward here:
>
>  1) make sure work on the solutions is moving forward in the 
> appropriate WGs, etc., and wait until publishing this document, with 
> mentioning the solutions.  Drawback is that it may take long time to 
> get these merged in the specification efforts.
>
>  2) remove all the references to solutions in this document (I believe 
> most of this was already done in -03 revision).

Yes, -03 has removed any references to solutions.

> For what it's worth, the status wrt solutions is as follows:
> [...]

There is another aspect, which is what to publish in the DNS, and this 
is where there is
overlap with the draft in DNSop "don't publish unreachable". 
Essentially, publishing IPv6 addresses
in the global DNS when one does not have global IPv6 connectivity is no 
different than
publishing IPv4 RFC1918 type addresses...

About default address, there is an issue for apps that are using UDP 
and are (miss?)configured
with an unreachable literal IPv6 address. This is typically the case 
for a DNS stub-resolver
that is configured with a list of literal addresses. We had to 
introduce an extra rule
to take care of that.

If you are confident that progress can be made quickly on all those 
fronts, it may be worth
holding back the publication of the draft until resolution of those 
issues, however, i have to admit that
I'm a bit pessimistic...

	- Alain.






From owner-v6ops@ops.ietf.org  Thu Nov 18 14:00:15 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21988
	for <v6ops-archive@lists.ietf.org>; Thu, 18 Nov 2004 14:00:15 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
	id 1CUrVM-000M7V-FO
	for v6ops-data@psg.com; Thu, 18 Nov 2004 18:59:40 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.43 (FreeBSD))
	id 1CUrVK-000M77-R9
	for v6ops@ops.ietf.org; Thu, 18 Nov 2004 18:59:39 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id iAIIxaZ23642;
	Thu, 18 Nov 2004 20:59:36 +0200
Date: Thu, 18 Nov 2004 20:59:36 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: Alain Durand <Alain.Durand@Sun.COM>
cc: v6ops@ops.ietf.org
Subject: Re: Situation with draft-ietf-v6ops-v6onbydefault-03.txt
In-Reply-To: <76E2D358-398F-11D9-B9DD-00039376A6AA@sun.com>
Message-ID: <Pine.LNX.4.61.0411182054230.23462@netcore.fi>
References: <Pine.LNX.4.61.0411171605220.17649@netcore.fi>
 <76E2D358-398F-11D9-B9DD-00039376A6AA@sun.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.0.1
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

On Thu, 18 Nov 2004, Alain Durand wrote:
> Thank you for starting this thread. Please note that there is also a 
> companion draft, draft-ietf-v6ops-onlinkassumption-02.txt that 
> provides that rationale for the change in RFC2461 about on-link 
> assumption. What should we do about this draft?
> 	- publish it as Info RFC to document the rationale for the change in 
> the update of RFC2461?
> 	- same thing, but publish it simultaneously as 2461bis?
> 	- let it expire has it has served its purpose.

It's in the similar state as this document; the second seems to make 
most sense (if it's not merged back to v6onbydefault), as RFC2461(bis) 
does not document the justification for the on-link assumption or its 
removal, and I think it'd be useful to have a document to show to 
people who would come up and ask why this is done.

> There is another aspect, which is what to publish in the DNS, and 
> this is where there is overlap with the draft in DNSop "don't 
> publish unreachable". Essentially, publishing IPv6 addresses in the 
> global DNS when one does not have global IPv6 connectivity is no 
> different than publishing IPv4 RFC1918 type addresses...

Agree.  This was a tricky document with no clear progress at dnsop 
meeting.  Someone should take it up, and document the issues with 
general unreachable address publication, as well as tradeoffs with ULA 
or similar addresses in the DNS.

> About default address, there is an issue for apps that are using UDP 
> and are (miss?)configured with an unreachable literal IPv6 address. 
> This is typically the case for a DNS stub-resolver that is 
> configured with a list of literal addresses. We had to introduce an 
> extra rule to take care of that.

Could you elaborate a bit what you mean by that?

> If you are confident that progress can be made quickly on all those 
> fronts, it may be worth holding back the publication of the draft 
> until resolution of those issues, however, i have to admit that I'm 
> a bit pessimistic...

The difficult part is being able to make progress with the TCP 
modification.  Within a couple of weeks, I believe there will be 
better knowledge how it turns out.  If you care, you could check the 
tcpm WG archives for the (long) thread, and see if you have something 
to contribute.

-- 
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 owner-v6ops@ops.ietf.org  Thu Nov 18 14:36:37 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24896
	for <v6ops-archive@lists.ietf.org>; Thu, 18 Nov 2004 14:36:36 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
	id 1CUs3s-00002d-S4
	for v6ops-data@psg.com; Thu, 18 Nov 2004 19:35:20 +0000
Received: from [192.18.98.36] (helo=brmea-mail-4.sun.com)
	by psg.com with esmtp (Exim 4.43 (FreeBSD))
	id 1CUs3r-00002O-RY
	for v6ops@ops.ietf.org; Thu, 18 Nov 2004 19:35:20 +0000
Received: from esunmail ([129.147.156.34])
	by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id iAIJZJun024127
	for <v6ops@ops.ietf.org>; Thu, 18 Nov 2004 12:35:19 -0700 (MST)
Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM
 (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004))
 with ESMTP id <0I7E00FX63QUCK@edgemail1.Central.Sun.COM> for
 v6ops@ops.ietf.org; Thu, 18 Nov 2004 12:35:19 -0700 (MST)
Received: from [192.168.1.2] ([66.93.39.75])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004))
 with ESMTPSA id <0I7E00EGC3QSVV@mail.sun.net> for v6ops@ops.ietf.org; Thu,
 18 Nov 2004 12:35:18 -0700 (MST)
Date: Thu, 18 Nov 2004 11:35:13 -0800
From: Alain Durand <Alain.Durand@Sun.COM>
Subject: Re: Situation with draft-ietf-v6ops-v6onbydefault-03.txt
In-reply-to: <Pine.LNX.4.61.0411182054230.23462@netcore.fi>
To: Pekka Savola <pekkas@netcore.fi>
Cc: v6ops@ops.ietf.org
Message-id: <F7CE19BF-3998-11D9-B9DD-00039376A6AA@sun.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.619)
Content-type: text/plain; charset=US-ASCII; format=flowed
Content-transfer-encoding: 7BIT
References: <Pine.LNX.4.61.0411171605220.17649@netcore.fi>
 <76E2D358-398F-11D9-B9DD-00039376A6AA@sun.com>
 <Pine.LNX.4.61.0411182054230.23462@netcore.fi>
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.0.1
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7BIT


On Nov 18, 2004, at 10:59 AM, Pekka Savola wrote:

>> There is another aspect, which is what to publish in the DNS, and 
>> this is where there is overlap with the draft in DNSop "don't publish 
>> unreachable". Essentially, publishing IPv6 addresses in the global 
>> DNS when one does not have global IPv6 connectivity is no different 
>> than publishing IPv4 RFC1918 type addresses...
>
> Agree.  This was a tricky document with no clear progress at dnsop 
> meeting.  Someone should take it up, and document the issues with 
> general unreachable address publication, as well as tradeoffs with ULA 
> or similar addresses in the DNS.

Tim Chown & I have half committed to take that one

>> About default address, there is an issue for apps that are using UDP 
>> and are (miss?)configured with an unreachable literal IPv6 address. 
>> This is typically the case for a DNS stub-resolver that is configured 
>> with a list of literal addresses. We had to introduce an extra rule 
>> to take care of that.
>
> Could you elaborate a bit what you mean by that?

I have to take my previous statement back, I was a bit confused.
I meant to refer to the suggested rule 2.5 for address selection in
section "2.1  Problems with Default Address Selection for IPv6"
of draft-ietf-v6ops-v6onbydefault-03.txt

It essentially says that choosing a src address with different 
reachability
properties than the destination address (here src = link local, dst = 
global,
but there might be other bad combinations with ULA) is a bad idea.

	- Alain.




From owner-v6ops@ops.ietf.org  Fri Nov 19 05:51:12 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15290
	for <v6ops-archive@lists.ietf.org>; Fri, 19 Nov 2004 05:51:11 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
	id 1CV6Ix-000CfO-UW
	for v6ops-data@psg.com; Fri, 19 Nov 2004 10:47:51 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.43 (FreeBSD))
	id 1CV6Iw-000Cem-2L
	for v6ops@ops.ietf.org; Fri, 19 Nov 2004 10:47:51 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id iAJAlkh11922
	for <v6ops@ops.ietf.org>; Fri, 19 Nov 2004 12:47:46 +0200
Date: Fri, 19 Nov 2004 12:47:46 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: v6ops@ops.ietf.org
Subject: Re: Consensus for moving NAT-PT to experimental?
In-Reply-To: <Pine.LNX.4.61.0411111940140.25704@netcore.fi>
Message-ID: <Pine.LNX.4.61.0411191245550.11300@netcore.fi>
References: <Pine.LNX.4.61.0411111940140.25704@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.0.1
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

(co-chair hat on)

There is rough consensus for moving NAT-PT to experimental.

Authors, please revise the draft by removing the considerations about 
the scenarios, and just listing NAT-PT issues, and pass it by the 
chairs; let's submit the next version as a WG document.

(hat off)

On Thu, 11 Nov 2004, Pekka Savola wrote:
> (co-chair hat on)
>
> At the meeting, there was almost unanimous consensus for moving NAT-PT to 
> experimental.
>
> The approach which seemed to have significant support was splitting the 
> document draft-aoun-v6ops-natpt-deprecate-00.txt in two: the one describing 
> issues (which would also request the reclassification), and one describing 
> different usage (or non-usage) scenarios.
>
> If you believe this is a bad approach, please voice your concerns within a 
> week, by 18th November.  Thanks!
>
> (hat off)
>
>

-- 
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 owner-v6ops@ops.ietf.org  Fri Nov 19 06:32:54 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18641
	for <v6ops-archive@lists.ietf.org>; Fri, 19 Nov 2004 06:32:54 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
	id 1CV707-000Jvd-Ty
	for v6ops-data@psg.com; Fri, 19 Nov 2004 11:32:27 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.43 (FreeBSD))
	id 1CV706-000Juy-NF
	for v6ops@ops.ietf.org; Fri, 19 Nov 2004 11:32:27 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id iAJBWNf13070;
	Fri, 19 Nov 2004 13:32:23 +0200
Date: Fri, 19 Nov 2004 13:32:23 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: Alain Durand <Alain.Durand@Sun.COM>
cc: v6ops@ops.ietf.org
Subject: Re: Situation with draft-ietf-v6ops-v6onbydefault-03.txt
In-Reply-To: <F7CE19BF-3998-11D9-B9DD-00039376A6AA@sun.com>
Message-ID: <Pine.LNX.4.61.0411191330510.11300@netcore.fi>
References: <Pine.LNX.4.61.0411171605220.17649@netcore.fi>
 <76E2D358-398F-11D9-B9DD-00039376A6AA@sun.com> <Pine.LNX.4.61.0411182054230.23462@netcore.fi>
 <F7CE19BF-3998-11D9-B9DD-00039376A6AA@sun.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.0.1
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

On Thu, 18 Nov 2004, Alain Durand wrote:
>>> There is another aspect, which is what to publish in the DNS, and this is 
>>> where there is overlap with the draft in DNSop "don't publish 
>>> unreachable". Essentially, publishing IPv6 addresses in the global DNS 
>>> when one does not have global IPv6 connectivity is no different than 
>>> publishing IPv4 RFC1918 type addresses...
>> 
>> Agree.  This was a tricky document with no clear progress at dnsop meeting. 
>> Someone should take it up, and document the issues with general unreachable 
>> address publication, as well as tradeoffs with ULA or similar addresses in 
>> the DNS.
>
> Tim Chown & I have half committed to take that one

Great!

>>> About default address, there is an issue for apps that are using UDP and 
>>> are (miss?)configured with an unreachable literal IPv6 address. This is 
>>> typically the case for a DNS stub-resolver that is configured with a list 
>>> of literal addresses. We had to introduce an extra rule to take care of 
>>> that.
>> 
>> Could you elaborate a bit what you mean by that?
>
> I have to take my previous statement back, I was a bit confused.
> I meant to refer to the suggested rule 2.5 for address selection in
> section "2.1  Problems with Default Address Selection for IPv6"
> of draft-ietf-v6ops-v6onbydefault-03.txt
>
> It essentially says that choosing a src address with different 
> reachability properties than the destination address (here src = 
> link local, dst = global, but there might be other bad combinations 
> with ULA) is a bad idea.

So, this is something that we need to keep bugging IPv6 WG about, I 
guess?

Maybe we need a (short) draft to describe the issues and possibly 
suggest solutions..

-- 
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 owner-v6ops@ops.ietf.org  Fri Nov 19 08:52:06 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02179
	for <v6ops-archive@lists.ietf.org>; Fri, 19 Nov 2004 08:52:05 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
	id 1CV99J-000H6e-Qn
	for v6ops-data@psg.com; Fri, 19 Nov 2004 13:50:05 +0000
Received: from [144.254.15.119] (helo=strange-brew.cisco.com)
	by psg.com with esmtp (Exim 4.43 (FreeBSD))
	id 1CV99H-000H5V-2X
	for v6ops@ops.ietf.org; Fri, 19 Nov 2004 13:50:03 +0000
Received: from gvandeve-w2k01.cisco.com (ams-clip-vpn-dhcp42.cisco.com [10.61.64.42])
	by strange-brew.cisco.com (8.11.7p1+Sun/8.8.8) with ESMTP id iAJDnl103053;
	Fri, 19 Nov 2004 14:49:47 +0100 (CET)
Message-Id: <4.3.2.7.2.20041119144501.02b5a7b0@strange-brew>
X-Sender: gvandeve@strange-brew
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 19 Nov 2004 14:49:41 +0100
To: Pekka Savola <pekkas@netcore.fi>
From: "Gunter Van de Velde (gvandeve)" <gvandeve@cisco.com>
Subject: Re: IPv6 Network Architecture Protection draft
Cc: Brian E Carpenter <brc@zurich.ibm.com>, ahain@cisco.com,
        ericlklein@softhome.net, rdroms@cisco.com, v6ops@ops.ietf.org
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_168509143==_.ALT"
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00,HTML_20_30,
	HTML_MESSAGE,MIME_QP_LONG_LINE autolearn=no version=3.0.1
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

--=====================_168509143==_.ALT
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: quoted-printable

many thanks for the review below. Kindly find some actions and
comments below:

At 14:31 8/11/2004 +0200, Pekka Savola wrote:
>On Thu, 14 Oct 2004, Brian E Carpenter wrote:
>>The authors would be interested in comments on the draft below.
>
>Thanks.  Mine below. I think this is an important and very well-written=
 draft.
>
>I recognize a number of recommendations/v6 approaches which I definitely=20
>don't like, but would rather see changed (if it was possible), but because=
=20
>this draft is meant more as a political document I understand why those=20
>(more or less) have to be in there...
>
>substantial
>-----------
>
>2.  Perceived benefits of NAT and its impact on IPv4
>
>    This section provides visibility into the generally perceived
>    benefits of the use of IPv4 NAT.  The goal of this description is not
>    to analyze these benefits or discus the rightfulness of the
>    perception, but to identify the connectivity and security
>    prerequisites to deploy IPv6 to functionally replace IPv4 combined
>    with a NAT device.
>
>=3D=3D> as said above, this is a practically good approach at finishing=
 this
>document in finite time.  I just hope it would have been possible to insert
>some enlightenment, possibly a subsection per existing subsection, saying
>why a particular concern is not such a big problem or is a bad idea.  You
>never know, someone could even be convinced about it.... :-)

Maybe we should do that in appendix or so. We have tried to provide
some ventilation or 2th thoughts on a certain perceived benefit, but we also
would like to avoid writing new rfc 2993.

We will however take your suggestion onboard in the working document
for the -01 compilation

>2.6.2  Small private networks
>2.6.3  Single user connection
>
>=3D=3D> do we dare to mention some ISPs' business models here, i.e., NAT=
 helps
>the customer to deploy as many devices as he wants in even residential,
>cheapo access deal?  ISP could force the user's hand if ISP only gave
>/128's.  On the other hand, then the user can just use tunneling like=
 Teredo
>or 6to4, and get v4-dependent v6 address space regardless of the ISP.

I added note for our further discussion.

>    This simple rule would create similar protection and security holes
>    the typical IPv4 NAT device will offer and may for example be enabled
>    by default on all broadband edge-routers.  but with that difference
>    that the security caveats will be documented, and may hence be
>    removed with the next revision of the rule.
>
>=3D=3D> this also needs to discuss how to not throw away the baby with the
>bathwater, i.e., how one could deploy e.g. new apps (like p2p) without
>having to do the same kind of firewall traversal as v4.  This probably
>would need some signalling mechanism or something.. Probably an issue to be
>investigated.

This sounds like the work that Jordi wants to achieve with his distributed=
=20
security
draft? I've added note that we need to discus this little broader in the
context of NAP.

>   An alternative method to hide the internal topology would be to use
>    MIPv6 internally where the public facing addresses (HA) are
>    consolidated on an edge Home Agent, then use MIP in tunnel mode to
>    the ULA as a COA.  This truly masks the internal topology as all
>    nodes with global access appear to share a common subnet.  (it
>    wouldn't really need to be a single subnet either so local policy can
>    run rampant trying to obscure addressing correlations.) There is no
>    reason that rack mounted devices shouldn't be considered mobile nodes
>    to mask the internal topology.
>
>=3D=3D> You're referring to using MIPv6 in a MIPv4-like manner, e.g., using
>bidirectional tunneling only, no route optimization.  This should be stated
>out explicitly. That's equivalent to running a VPN to a central server.
>This has issues e.g. relating to scalability and reliability of the server
>which should also be at least briefly mentioned.

ok, i added note in the working document.

>NOTE:
>
>    Is all of the material in this section, specifically the material
>    that does not directly address the "advantages" of IPv4 NAT,
>    necessary?
>
>=3D=3D> agree, most of this is irrelevant here.  I'd suggest, unless=
 something
>else is figured out, to moving the non-relevant parts to an appendix and
>figuring out later what should be the final destiny..

agree



>semi-editorial
>--------------
>
>    Once a list of available devices and IP addresses has been mapped, a
>    port-scan on these IP addresses can be performed.  A port scan is an
>    automated procedure of initiating sessions on every specified TCP
>    port to see whether the host replies.  If it does, a service is
>    running on the target port of the machine.  Different services run on
>    default ports.  For example, FTP usually runs on port 21, and HTTP
>    usually runs on port 80.  These open port cold be used for initiating
>    attacks on an end system.
>
>=3D=3D> there's UDP port scanning as well, in case the firewall is=
 returning
>port unreachables for the unfiltered ports (which tells which ports are
>passed by the firewall, or if there is no firewall, which ports are open at
>the host).

ok

>=3D=3D> this and a couple of other sections go a bit unnecessary in depth=
 to
>describe e.g., what port scanning is, but considering the target audience
>this is probably a good idea..

that was indeed our motivation to include it

>2.5  Independent control of addressing in a private network
>2.7  Multihoming and renumbering with NAT
>
>=3D=3D> these seem to be more tightly coupled, so would it make good sense=
 to
>move 2.7 as 2.6, and rename 2.6 as 2.7 (and respectively)?  If not, there
>should be a pointer from 2.5 (last paragraph) to section 2.7.

That will happen automatically as we currently plan to place the 2.6 in a=20
new case-study
chapter.

>    Based on the amount of connections and required network services the
>    network design and addressing dynamics are different.
>
>=3D=3D> what "connections"?  _simultaneous_?  TCP connections or flows in
>general?

This refers to physical connections. I can't see how to identify a physical
link any better in a simple way. maybe the terminology 'physical=20
interconnection' can
be used

>    3.  The size of the typical subnet ::/64 will make a network ping
>        sweep and resulting port-scan virtually impossible due to the
>        amount of possible combinations available
>
>=3D=3D> make explict ref to Tim Chown's document ?

makes sense.

>4.6.4  ISP/Carrier customer networks
>
>=3D=3D> this is roughly the same as 2.6.4, and needs to be updated ?
>(nothing v6-specific here..)

ok


>5.1  Universal any-to-any connectivity
>
>    One of the original design points of the Internet was any-to-any
>    connectivity.  The dramatic growth of Internet connected systems
>    coupled with the limited address space of the IPv4 protocol spawned
>    address conservation techniques.  NAT was introduced as a tool to
>    reduce demand on the limited IPv4 address pool, but the side effect
>    of the NAT technology was to remove the any-to-any connectivity
>    capability.  By removing the need for address conservation (and
>    therefore NAT), IPv6 returns the any-to-any connectivity model and
>    removes the limitations on application developers.  With the freedom
>    to innovate unconstrained by NAT traversal efforts, developers will
>    be able to focus on new advanced network services (i.e.  peer-to-peer
>    applications, IPv6 embedded IPsec communication between two
>    communicating devices, instant messaging, Internet telephony, etc..)
>    rather than focusing on discovering and traversing the increasingly
>    complex NAT environment.
>
>
>=3D=3D> maybe this needs reference to the default firewall policy section,=
 and
>the caveat about that causing issues for new any-to-any apps..

I added note on this in the working document for -01

>   IPv6 allows also for innovative usage of the IPv6 address length, and
>    makes it possible to embed the multicast 'Rendez-Vous Point' (or RP)
>    directly in the IPv6 multicast address when using ASM multicast.
>    this is not possible with limited size of the IPv4 address.
>
>=3D=3D> I guess it might also be worth saying that using this approach
>simplifies the multicast model considerably, making it easier to understand
>and to deploy.

I proposed following text based on your comment:

<snip>
     <t>IPv6 allows also for innovative usage of the IPv6 address length,=20
and makes
     it possible to embed the multicast 'Rendez-Vous Point' (or RP)=20
directly in the
     IPv6 multicast address when using ASM multicast. this is not possible=
=20
with
     limited size of the IPv4 address. This approach also simplifies the=20
multicast
     model considerably, making it easier to understand and deploy </t>
<end snip>

>    o  IPv6 has the IPsec technology embedded directly embedded into the
>       IPv6 protocol.  This allows for simpler peer-to-peer encryption
>       and authentication, while the usage of some other less secure
>       mechanisms is avoided (i.e.  md5 password hash for neighbor
>       authentication)
>
>=3D=3D> in all fairness, there is still the small matter of key/trust=
 management
>to consider, unless an opportunistic IPsec model is acceptable..

Added the note in the working document

>    o  On a local network, any user will have more security awareness.
>       This awareness will motivate the usage of simple firewall
>       applications/devices to be inserted on the border between the
>       external network and the local (or home network).
>
>=3D=3D> I didn't understand what this tried to say..

ack. We will make it more clear.

>    o  The technology to enable source-routing on a network
>       infrastructure has been enhanced to allow this feature to
>       function, without impacting the processing power of intermediate
>       network devices.  The only devices impacted with the
>       source-routing will be the source and destination node and the
>       intermediate source-routed nodes.  This impact behavior is
>       different if IPv4 is used, because then all intermediate devices
>       would have had to look into the source-route header.  Looking into
>       the source-route header consumed CPU power of these devices and
>       was generally discouraged to be enabled on a network due to
>       potential Denial-of-Service attack potential.
>
>=3D=3D> this is technically not correct.  Both v4 and v6 behave the same=
 way;
>the routing header is only processed by those nodes who are at the
>destination address (before it's changed), so on-path nodes don't need to
>peek at the packets.  I suggest this bullet be removed.

Will look deeper into it.
I always believed that a router falls back to CPU switching from the
moment an option is set in the IPv4 header as the router doesn't know
which options were used. This is one of the (many) reasons
ISP don't allow this through the network as it eats-up CPU cycles
and makes forwarding these packets slow.

but as you seem so certain i will double-check.

>6.  IPv6 gap analysis
>
>    Like IPv4 and any major standards effort, IPv6 standardization work
>    continues as deployment starts.
>
>=3D=3D> "as deployment starts" sounds as if deployment has not started yet=
=20
>;-). Maybe "is ongoing"?

ok :-)


>8.  Security Considerations
>
>    Various security and privacy benefits of both IPv4 NAT and native
>    IPv6 are discussed throughout this document.  It does not introduce
>    any new security concerns.
>
>=3D=3D> this section will probably need to expand a bit, but I guess it's=
 OK to
>keep it as is for now, to see how the recommendations develop.
>
>11  References
>
>=3D=3D> need to be split to normative/informative
>
>
>editorial
>---------
>
>    to analyze these benefits or discus the rightfulness of the
>
>=3D=3D> s/discus/discuss/

ok

>    which member of a family, which customer of an Internet caf=89, or
>
>=3D=3D> s/caf[weird character here]/cafe/

ok

>    of NAT to avoid the ongoing operational complexity of overlapping
>    addresses
>
>=3D=3D> add "." at the end.

ok

>    An example of a potential rule could be:
>
>=3D=3D> s/rule/set of firewall rules/

ok

>    This simple rule would create similar protection and security holes
>    the typical IPv4 NAT device will offer and may for example be enabled
>    by default on all broadband edge-routers.  but with that difference
>    that the security caveats will be documented, and may hence be
>    removed with the next revision of the rule.
>
>=3D=3D> s/but/But/, or something missing there?

ok

>4.5  independent control of addressing in a private network
>
>=3D=3D> s/in/In/

ok

>    route-injection could be done based on ::/128 host-routes to each
>
>=3D=3D> remove "::".

ok

>4.6.2  small private networks
>
>=3D=3D> s/small/Small/

ok

>    Operation Center (NOC) and are using either a dial-up connection or
>    broadband access..
>
>=3D=3D> remove the other "."

ok

>    o  IPv6 has the IPsec technology embedded directly embedded into the
>
>=3D=3D> kill extra "embedded"

ok


Many thanks for the review and the information provided.
Many of the topics will be included/considered in our working draft for the=
=20
-01 release.

Enjoy the weekend,
G/
--=====================_168509143==_.ALT
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
many thanks for the review below. Kindly find some actions and<br>
comments below:<br>
<br>
At 14:31 8/11/2004 +0200, Pekka Savola wrote:<br>
<blockquote type=3Dcite cite>On Thu, 14 Oct 2004, Brian E Carpenter
wrote:<br>
<blockquote type=3Dcite cite>The authors would be interested in comments on
the draft below.</blockquote><br>
Thanks.&nbsp; Mine below. I think this is an important and very
well-written draft.<br>
<br>
I recognize a number of recommendations/v6 approaches which I definitely
don't like, but would rather see changed (if it was possible), but
because this draft is meant more as a political document I understand why
those (more or less) have to be in there...<br>
<br>
substantial<br>
-----------<br>
<br>
2.&nbsp; Perceived benefits of NAT and its impact on IPv4<br>
<br>
&nbsp;&nbsp; This section provides visibility into the generally
perceived<br>
&nbsp;&nbsp; benefits of the use of IPv4 NAT.&nbsp; The goal of this
description is not<br>
&nbsp;&nbsp; to analyze these benefits or discus the rightfulness of
the<br>
&nbsp;&nbsp; perception, but to identify the connectivity and
security<br>
&nbsp;&nbsp; prerequisites to deploy IPv6 to functionally replace IPv4
combined<br>
&nbsp;&nbsp; with a NAT device.<br>
<br>
=3D=3D&gt; as said above, this is a practically good approach at finishing
this<br>
document in finite time.&nbsp; I just hope it would have been possible to
insert<br>
some enlightenment, possibly a subsection per existing subsection,
saying<br>
why a particular concern is not such a big problem or is a bad
idea.&nbsp; You<br>
never know, someone could even be convinced about it....
:-)</blockquote><br>
Maybe we should do that in appendix or so. We have tried to provide<br>
some ventilation or 2th thoughts on a certain perceived benefit, but we
also<br>
would like to avoid writing new rfc 2993. <br>
<br>
We will however take your suggestion onboard in the working document
<br>
for the -01 compilation<br>
<br>
<blockquote type=3Dcite cite>2.6.2&nbsp; Small private networks<br>
2.6.3&nbsp; Single user connection<br>
<br>
=3D=3D&gt; do we dare to mention some ISPs' business models here, i.e., NAT
helps<br>
the customer to deploy as many devices as he wants in even
residential,<br>
cheapo access deal?&nbsp; ISP could force the user's hand if ISP only
gave<br>
/128's.&nbsp; On the other hand, then the user can just use tunneling
like Teredo<br>
or 6to4, and get v4-dependent v6 address space regardless of the
ISP.</blockquote><br>
I added note for our further discussion.<br>
<br>
<blockquote type=3Dcite cite>&nbsp;&nbsp; This simple rule would create
similar protection and security holes<br>
&nbsp;&nbsp; the typical IPv4 NAT device will offer and may for example
be enabled<br>
&nbsp;&nbsp; by default on all broadband edge-routers.&nbsp; but with
that difference<br>
&nbsp;&nbsp; that the security caveats will be documented, and may hence
be<br>
&nbsp;&nbsp; removed with the next revision of the rule.<br>
<br>
=3D=3D&gt; this also needs to discuss how to not throw away the baby with
the<br>
bathwater, i.e., how one could deploy e.g. new apps (like p2p)
without<br>
having to do the same kind of firewall traversal as v4.&nbsp; This
probably<br>
would need some signalling mechanism or something.. Probably an issue to
be<br>
investigated.</blockquote><br>
This sounds like the work that Jordi wants to achieve with his
distributed security<br>
draft? I've added note that we need to discus this little broader in the
<br>
context of NAP.<br>
<br>
<blockquote type=3Dcite cite>&nbsp; An alternative method to hide the
internal topology would be to use<br>
&nbsp;&nbsp; MIPv6 internally where the public facing addresses (HA)
are<br>
&nbsp;&nbsp; consolidated on an edge Home Agent, then use MIP in tunnel
mode to<br>
&nbsp;&nbsp; the ULA as a COA.&nbsp; This truly masks the internal
topology as all<br>
&nbsp;&nbsp; nodes with global access appear to share a common
subnet.&nbsp; (it<br>
&nbsp;&nbsp; wouldn't really need to be a single subnet either so local
policy can<br>
&nbsp;&nbsp; run rampant trying to obscure addressing correlations.)
There is no<br>
&nbsp;&nbsp; reason that rack mounted devices shouldn't be considered
mobile nodes<br>
&nbsp;&nbsp; to mask the internal topology.<br>
<br>
=3D=3D&gt; You're referring to using MIPv6 in a MIPv4-like manner, e.g.,
using<br>
bidirectional tunneling only, no route optimization.&nbsp; This should be
stated<br>
out explicitly. That's equivalent to running a VPN to a central
server.<br>
This has issues e.g. relating to scalability and reliability of the
server<br>
which should also be at least briefly mentioned.</blockquote><br>
ok, i added note in the working document.<br>
<br>
<blockquote type=3Dcite cite>NOTE:<br>
<br>
&nbsp;&nbsp; Is all of the material in this section, specifically the
material<br>
&nbsp;&nbsp; that does not directly address the &quot;advantages&quot; of
IPv4 NAT,<br>
&nbsp;&nbsp; necessary?<br>
<br>
=3D=3D&gt; agree, most of this is irrelevant here.&nbsp; I'd suggest, unless
something<br>
else is figured out, to moving the non-relevant parts to an appendix
and<br>
figuring out later what should be the final destiny..<br>
</blockquote><br>
agree<br>
<br>
<br>
<br>
<blockquote type=3Dcite cite>semi-editorial<br>
--------------<br>
<br>
&nbsp;&nbsp; Once a list of available devices and IP addresses has been
mapped, a<br>
&nbsp;&nbsp; port-scan on these IP addresses can be performed.&nbsp; A
port scan is an<br>
&nbsp;&nbsp; automated procedure of initiating sessions on every
specified TCP<br>
&nbsp;&nbsp; port to see whether the host replies.&nbsp; If it does, a
service is<br>
&nbsp;&nbsp; running on the target port of the machine.&nbsp; Different
services run on<br>
&nbsp;&nbsp; default ports.&nbsp; For example, FTP usually runs on port
21, and HTTP<br>
&nbsp;&nbsp; usually runs on port 80.&nbsp; These open port cold be used
for initiating<br>
&nbsp;&nbsp; attacks on an end system.<br>
<br>
=3D=3D&gt; there's UDP port scanning as well, in case the firewall is
returning<br>
port unreachables for the unfiltered ports (which tells which ports
are<br>
passed by the firewall, or if there is no firewall, which ports are open
at<br>
the host).</blockquote><br>
ok<br>
<br>
<blockquote type=3Dcite cite>=3D=3D&gt; this and a couple of other sections =
go
a bit unnecessary in depth to<br>
describe e.g., what port scanning is, but considering the target
audience<br>
this is probably a good idea..</blockquote><br>
that was indeed our motivation to include it<br>
<br>
<blockquote type=3Dcite cite>2.5&nbsp; Independent control of addressing in
a private network<br>
2.7&nbsp; Multihoming and renumbering with NAT<br>
<br>
=3D=3D&gt; these seem to be more tightly coupled, so would it make good sens=
e
to<br>
move 2.7 as 2.6, and rename 2.6 as 2.7 (and respectively)?&nbsp; If not,
there<br>
should be a pointer from 2.5 (last paragraph) to section
2.7.</blockquote><br>
That will happen automatically as we currently plan to place the 2.6 in a
new case-study <br>
chapter.<br>
<br>
<blockquote type=3Dcite cite>&nbsp;&nbsp; Based on the amount of
connections and required network services the<br>
&nbsp;&nbsp; network design and addressing dynamics are different.<br>
<br>
=3D=3D&gt; what &quot;connections&quot;?&nbsp; _simultaneous_?&nbsp; TCP
connections or flows in<br>
general?<br>
</blockquote><br>
This refers to physical connections. I can't see how to identify a
physical<br>
link any better in a simple way. maybe the terminology 'physical
interconnection' can <br>
be used<br>
<br>
<blockquote type=3Dcite cite>&nbsp;&nbsp; 3.&nbsp; The size of the typical
subnet ::/64 will make a network ping<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; sweep and resulting port-scan
virtually impossible due to the<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; amount of possible combinations
available<br>
<br>
=3D=3D&gt; make explict ref to Tim Chown's document ?</blockquote><br>
makes sense.<br>
<br>
<blockquote type=3Dcite cite>4.6.4&nbsp; ISP/Carrier customer=20
networks<br>
<br>
=3D=3D&gt; this is roughly the same as 2.6.4, and needs to be updated ?<br>
(nothing v6-specific here..)</blockquote><br>
ok<br>
<br>
<br>
<blockquote type=3Dcite cite>5.1&nbsp; Universal any-to-any
connectivity<br>
<br>
&nbsp;&nbsp; One of the original design points of the Internet was
any-to-any<br>
&nbsp;&nbsp; connectivity.&nbsp; The dramatic growth of Internet
connected systems<br>
&nbsp;&nbsp; coupled with the limited address space of the IPv4 protocol
spawned<br>
&nbsp;&nbsp; address conservation techniques.&nbsp; NAT was introduced as
a tool to<br>
&nbsp;&nbsp; reduce demand on the limited IPv4 address pool, but the side
effect<br>
&nbsp;&nbsp; of the NAT technology was to remove the any-to-any
connectivity<br>
&nbsp;&nbsp; capability.&nbsp; By removing the need for address
conservation (and<br>
&nbsp;&nbsp; therefore NAT), IPv6 returns the any-to-any connectivity
model and<br>
&nbsp;&nbsp; removes the limitations on application developers.&nbsp;
With the freedom<br>
&nbsp;&nbsp; to innovate unconstrained by NAT traversal efforts,
developers will<br>
&nbsp;&nbsp; be able to focus on new advanced network services
(i.e.&nbsp; peer-to-peer<br>
&nbsp;&nbsp; applications, IPv6 embedded IPsec communication between
two<br>
&nbsp;&nbsp; communicating devices, instant messaging, Internet
telephony, etc..)<br>
&nbsp;&nbsp; rather than focusing on discovering and traversing the
increasingly<br>
&nbsp;&nbsp; complex NAT environment.<br>
<br>
<br>
=3D=3D&gt; maybe this needs reference to the default firewall policy section=
,
and<br>
the caveat about that causing issues for new any-to-any
apps..</blockquote><br>
I added note on this in the working document for -01<br>
<br>
<blockquote type=3Dcite cite>&nbsp; IPv6 allows also for innovative usage
of the IPv6 address length, and<br>
&nbsp;&nbsp; makes it possible to embed the multicast 'Rendez-Vous Point'
(or RP)<br>
&nbsp;&nbsp; directly in the IPv6 multicast address when using ASM
multicast.<br>
&nbsp;&nbsp; this is not possible with limited size of the IPv4
address.<br>
<br>
=3D=3D&gt; I guess it might also be worth saying that using this
approach<br>
simplifies the multicast model considerably, making it easier to
understand<br>
and to deploy.</blockquote><br>
I proposed following text based on your comment:<br>
<br>
&lt;snip&gt;<br>
<font face=3D"Courier New, Courier">&nbsp;&nbsp;&nbsp; &lt;t&gt;IPv6 allows
also for innovative usage of the IPv6 address length, and makes <br>
&nbsp;&nbsp;&nbsp; it possible to embed the multicast 'Rendez-Vous Point'
(or RP) directly in the<br>
&nbsp;&nbsp;&nbsp; IPv6 multicast address when using ASM multicast. this
is not possible with <br>
&nbsp;&nbsp;&nbsp; limited size of the IPv4 address. This approach also
simplifies the multicast<br>
&nbsp;&nbsp;&nbsp; model considerably, making it easier to understand and
deploy &lt;/t&gt;<br>
</font>&lt;end snip&gt;<br>
<br>
<blockquote type=3Dcite cite>&nbsp;&nbsp; o&nbsp; IPv6 has the IPsec
technology embedded directly embedded into the<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; IPv6 protocol.&nbsp; This allows for
simpler peer-to-peer encryption<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; and authentication, while the usage of
some other less secure<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; mechanisms is avoided (i.e.&nbsp; md5
password hash for neighbor<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; authentication)<br>
<br>
=3D=3D&gt; in all fairness, there is still the small matter of key/trust
management<br>
to consider, unless an opportunistic IPsec model is
acceptable..</blockquote><br>
Added the note in the working document<br>
<br>
<blockquote type=3Dcite cite>&nbsp;&nbsp; o&nbsp; On a local network, any
user will have more security awareness.<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This awareness will motivate the usage of
simple firewall<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; applications/devices to be inserted on the
border between the<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; external network and the local (or home
network).<br>
<br>
=3D=3D&gt; I didn't understand what this tried to say..</blockquote><br>
ack. We will make it more clear.<br>
<br>
<blockquote type=3Dcite cite>&nbsp;&nbsp; o&nbsp; The technology to enable
source-routing on a network<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; infrastructure has been enhanced to allow
this feature to<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; function, without impacting the processing
power of intermediate<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; network devices.&nbsp; The only devices
impacted with the<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; source-routing will be the source and
destination node and the<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; intermediate source-routed nodes.&nbsp;
This impact behavior is<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; different if IPv4 is used, because then
all intermediate devices<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; would have had to look into the
source-route header.&nbsp; Looking into<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the source-route header consumed CPU power
of these devices and<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; was generally discouraged to be enabled on
a network due to<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; potential Denial-of-Service attack
potential.<br>
<br>
=3D=3D&gt; this is technically not correct.&nbsp; Both v4 and v6 behave the
same way;<br>
the routing header is only processed by those nodes who are at the<br>
destination address (before it's changed), so on-path nodes don't need
to<br>
peek at the packets.&nbsp; I suggest this bullet be
removed.</blockquote><br>
Will look deeper into it. <br>
I always believed that a router falls back to CPU switching from the
<br>
moment an option is set in the IPv4 header as the router doesn't
know<br>
which options were used. This is one of the (many) reasons<br>
ISP don't allow this through the network as it eats-up CPU cycles<br>
and makes forwarding these packets slow. <br>
<br>
but as you seem so certain i will double-check.<br>
<br>
<blockquote type=3Dcite cite>6.&nbsp; IPv6 gap analysis<br>
<br>
&nbsp;&nbsp; Like IPv4 and any major standards effort, IPv6
standardization work<br>
&nbsp;&nbsp; continues as deployment starts.<br>
<br>
=3D=3D&gt; &quot;as deployment starts&quot; sounds as if deployment has not
started yet ;-). Maybe &quot;is ongoing&quot;?</blockquote><br>
ok :-)<br>
<br>
<br>
<blockquote type=3Dcite cite>8.&nbsp; Security Considerations<br>
<br>
&nbsp;&nbsp; Various security and privacy benefits of both IPv4 NAT and
native<br>
&nbsp;&nbsp; IPv6 are discussed throughout this document.&nbsp; It does
not introduce<br>
&nbsp;&nbsp; any new security concerns.<br>
<br>
=3D=3D&gt; this section will probably need to expand a bit, but I guess it's
OK to<br>
keep it as is for now, to see how the recommendations develop.<br>
<br>
11&nbsp; References<br>
<br>
=3D=3D&gt; need to be split to normative/informative<br>
<br>
<br>
editorial<br>
---------<br>
<br>
&nbsp;&nbsp; to analyze these benefits or discus the rightfulness of
the<br>
<br>
=3D=3D&gt; s/discus/discuss/</blockquote><br>
ok<br>
<br>
<blockquote type=3Dcite cite>&nbsp;&nbsp; which member of a family, which
customer of an Internet caf=89, or<br>
<br>
=3D=3D&gt; s/caf[weird character here]/cafe/</blockquote><br>
ok<br>
<br>
<blockquote type=3Dcite cite>&nbsp;&nbsp; of NAT to avoid the ongoing
operational complexity of overlapping<br>
&nbsp;&nbsp; addresses<br>
<br>
=3D=3D&gt; add &quot;.&quot; at the end.</blockquote><br>
ok<br>
<br>
<blockquote type=3Dcite cite>&nbsp;&nbsp; An example of a potential rule
could be:<br>
<br>
=3D=3D&gt; s/rule/set of firewall rules/</blockquote><br>
ok<br>
<br>
<blockquote type=3Dcite cite>&nbsp;&nbsp; This simple rule would create
similar protection and security holes<br>
&nbsp;&nbsp; the typical IPv4 NAT device will offer and may for example
be enabled<br>
&nbsp;&nbsp; by default on all broadband edge-routers.&nbsp; but with
that difference<br>
&nbsp;&nbsp; that the security caveats will be documented, and may hence
be<br>
&nbsp;&nbsp; removed with the next revision of the rule.<br>
<br>
=3D=3D&gt; s/but/But/, or something missing there?</blockquote><br>
ok<br>
<br>
<blockquote type=3Dcite cite>4.5&nbsp; independent control of addressing in
a private network<br>
<br>
=3D=3D&gt; s/in/In/</blockquote><br>
ok<br>
<br>
<blockquote type=3Dcite cite>&nbsp;&nbsp; route-injection could be done
based on ::/128 host-routes to each<br>
<br>
=3D=3D&gt; remove &quot;::&quot;.</blockquote><br>
ok<br>
<br>
<blockquote type=3Dcite cite>4.6.2&nbsp; small private networks<br>
<br>
=3D=3D&gt; s/small/Small/</blockquote><br>
ok<br>
<br>
<blockquote type=3Dcite cite>&nbsp;&nbsp; Operation Center (NOC) and are
using either a dial-up connection or<br>
&nbsp;&nbsp; broadband access..<br>
<br>
=3D=3D&gt; remove the other &quot;.&quot;</blockquote><br>
ok<br>
<br>
<blockquote type=3Dcite cite>&nbsp;&nbsp; o&nbsp; IPv6 has the IPsec
technology embedded directly embedded into the<br>
<br>
=3D=3D&gt; kill extra &quot;embedded&quot;</blockquote><br>
ok<br>
<br>
<br>
Many thanks for the review and the information provided.<br>
Many of the topics will be included/considered in our working draft for
the -01 release.<br>
<br>
Enjoy the weekend,<br>
G/</html>

--=====================_168509143==_.ALT--




From owner-v6ops@ops.ietf.org  Fri Nov 19 11:29:17 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17911
	for <v6ops-archive@lists.ietf.org>; Fri, 19 Nov 2004 11:29:16 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
	id 1CVBbl-000Fas-PR
	for v6ops-data@psg.com; Fri, 19 Nov 2004 16:27:37 +0000
Received: from [47.164.128.120] (helo=zctfs063.nortelnetworks.com)
	by psg.com with esmtp (Exim 4.43 (FreeBSD))
	id 1CVBbi-000Fa2-6V
	for v6ops@ops.ietf.org; Fri, 19 Nov 2004 16:27:34 +0000
Received: from zctfc040.europe.nortel.com (zctfc040.europe.nortel.com [47.164.129.95])
	by zctfs063.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id iAJGRVD17847
	for <v6ops@ops.ietf.org>; Fri, 19 Nov 2004 17:27:31 +0100 (MET)
Received: by zctfc040.europe.nortel.com with Internet Mail Service (5.5.2653.19)
	id <XA6NK7ZG>; Fri, 19 Nov 2004 17:27:28 +0100
Message-ID: <8F20221FB47FD51190AD00508BCF36BA0D45829A@znsgy0k3.europe.nortel.com>
From: "Elwyn Davies" <elwynd@nortelnetworks.com>
To: v6ops@ops.ietf.org
Subject: RE: Consensus for moving NAT-PT to experimental?
Date: Fri, 19 Nov 2004 17:27:25 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C4CE54.A79E4F22"
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,HTML_50_60,
	HTML_MESSAGE autolearn=ham version=3.0.1
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C4CE54.A79E4F22
Content-Type: text/plain

OK.

we'll get to it.

Regards,
Elwyn Davies

> -----Original Message-----
> From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] 
> Sent: 19 November 2004 10:48
> To: v6ops@ops.ietf.org
> Subject: Re: Consensus for moving NAT-PT to experimental?
> 
> 
> (co-chair hat on)
> 
> There is rough consensus for moving NAT-PT to experimental.
> 
> Authors, please revise the draft by removing the considerations about 
> the scenarios, and just listing NAT-PT issues, and pass it by the 
> chairs; let's submit the next version as a WG document.
> 
> (hat off)
> 
> On Thu, 11 Nov 2004, Pekka Savola wrote:
> > (co-chair hat on)
> >
> > At the meeting, there was almost unanimous consensus for 
> moving NAT-PT to 
> > experimental.
> >
> > The approach which seemed to have significant support was 
> splitting the 
> > document draft-aoun-v6ops-natpt-deprecate-00.txt in two: 
> the one describing 
> > issues (which would also request the reclassification), and 
> one describing 
> > different usage (or non-usage) scenarios.
> >
> > If you believe this is a bad approach, please voice your 
> concerns within a 
> > week, by 18th November.  Thanks!
> >
> > (hat off)
> >
> >
> 
> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> 
> 
> 

------_=_NextPart_001_01C4CE54.A79E4F22
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2658.2">
<TITLE>RE: Consensus for moving NAT-PT to experimental?</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>OK.</FONT>
</P>

<P><FONT SIZE=3D2>we'll get to it.</FONT>
</P>

<P><FONT SIZE=3D2>Regards,</FONT>
<BR><FONT SIZE=3D2>Elwyn Davies</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: owner-v6ops@ops.ietf.org [<A =
HREF=3D"mailto:owner-v6ops@ops.ietf.org">mailto:owner-v6ops@ops.ietf.org=
</A>] </FONT>
<BR><FONT SIZE=3D2>&gt; Sent: 19 November 2004 10:48</FONT>
<BR><FONT SIZE=3D2>&gt; To: v6ops@ops.ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: Consensus for moving NAT-PT to =
experimental?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; (co-chair hat on)</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; There is rough consensus for moving NAT-PT to =
experimental.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Authors, please revise the draft by removing =
the considerations about </FONT>
<BR><FONT SIZE=3D2>&gt; the scenarios, and just listing NAT-PT issues, =
and pass it by the </FONT>
<BR><FONT SIZE=3D2>&gt; chairs; let's submit the next version as a WG =
document.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; (hat off)</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; On Thu, 11 Nov 2004, Pekka Savola wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; (co-chair hat on)</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; At the meeting, there was almost unanimous =
consensus for </FONT>
<BR><FONT SIZE=3D2>&gt; moving NAT-PT to </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; experimental.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; The approach which seemed to have =
significant support was </FONT>
<BR><FONT SIZE=3D2>&gt; splitting the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; document =
draft-aoun-v6ops-natpt-deprecate-00.txt in two: </FONT>
<BR><FONT SIZE=3D2>&gt; the one describing </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; issues (which would also request the =
reclassification), and </FONT>
<BR><FONT SIZE=3D2>&gt; one describing </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; different usage (or non-usage) =
scenarios.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; If you believe this is a bad approach, =
please voice your </FONT>
<BR><FONT SIZE=3D2>&gt; concerns within a </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; week, by 18th November.&nbsp; =
Thanks!</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; (hat off)</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; -- </FONT>
<BR><FONT SIZE=3D2>&gt; Pekka =
Savola&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;You each name yourselves king, yet =
the</FONT>
<BR><FONT SIZE=3D2>&gt; Netcore =
Oy&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; kingdom =
bleeds.&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; Systems. Networks. Security. -- George R.R. =
Martin: A Clash of Kings</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C4CE54.A79E4F22--



From owner-v6ops@ops.ietf.org  Fri Nov 19 14:31:40 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04882
	for <v6ops-archive@lists.ietf.org>; Fri, 19 Nov 2004 14:31:40 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
	id 1CVESS-000LuS-2Q
	for v6ops-data@psg.com; Fri, 19 Nov 2004 19:30:12 +0000
Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com)
	by psg.com with esmtp (Exim 4.43 (FreeBSD))
	id 1CVESP-000Ltu-V5
	for v6ops@ops.ietf.org; Fri, 19 Nov 2004 19:30:09 +0000
Received: from rtp-core-2.cisco.com (64.102.124.13)
  by sj-iport-2.cisco.com with ESMTP; 19 Nov 2004 11:32:36 -0800
Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iAJJU5Wf017777;
	Fri, 19 Nov 2004 14:30:06 -0500 (EST)
Received: from cpopovic-w2k01.cisco.com (dhcp-64-102-39-89.cisco.com [64.102.39.89])
	by fruitpie.cisco.com (MOS 3.4.6-GR)
	with ESMTP id BDM91686;
	Fri, 19 Nov 2004 11:30:04 -0800 (PST)
Message-Id: <4.3.2.7.2.20041119135818.023ccda0@fruitpie.cisco.com>
X-Sender: cpopovic@fruitpie.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 19 Nov 2004 14:30:04 -0500
To: Gert Doering <gert@Space.Net>
From: Ciprian Popoviciu <cpopovic@cisco.com>
Subject: Re: ISP IPv6 Deployment Scenarios in Broadband Access
Cc: Pekka Savola <pekkas@netcore.fi>, v6ops@ops.ietf.org,
        Salman Asadullah <sasad@cisco.com>, adeel Ahmed <adahmed@cisco.com>
In-Reply-To: <20041118143631.GY84850@Space.Net>
References: <Pine.LNX.4.61.0411050830580.3277@netcore.fi>
 <4.3.2.7.2.20041021152613.0257d200@fruitpie.cisco.com>
 <Pine.LNX.4.61.0411050830580.3277@netcore.fi>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham 
	version=3.0.1
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk


Hello Gert,

Please see comments/answers in line ...

At 03:36 PM 11/18/2004 +0100, Gert Doering wrote:
>Hi,
>
>On Fri, Nov 05, 2004 at 08:42:14AM +0200, Pekka Savola wrote:
> > An operator which has deployed bridged-mode DSL ('RBE') said that the
> > only solution for providing bulk v6 access at the moment is requiring
> > the use of DHCPv6 for address assignment (i.e.: because DHCPv4 is
> > snooped for v4, the vendors seem to have implemented the same kind of
> > snooping for v6 w/ DHCPv6).
>[..]
> >  4) putting all the customers' v6 prefix information in a RADIUS or
> > similar database, so that the advertisement information could be
> > digged up from there.  A lot of work, and does not work automatically.
> > This would also need some glue between bulk config and RADIUS.
>
>How are people envisioning "bulk access with IPv6" anyway?

Do you mean wholesale model where the NAP doesn't handle addressing?


>I'm wondering specifically about the nature of the IPv6 allocations
>- are "operators" planning to do dynamic IPv6 allocations (today you get
>a dynamic IPv4 /32, in the future you get a dynamic IPv6 /64)?
>
>Or are people planning to assign static /48s?

In these broadband deployments there is an IPv6 prefix on the 
link/virtual-link to each customer. The address allocation in some of these 
deployments is done in two ways:
1) The /64 is assigned to the link/virtual-link between the access router 
and the customer. The customer then uses autoconfig for its hosts that are 
all on the same network.
2) There is a /64 assigned to the link/virtual-link between the access 
router and the customer but DHCP-PD is used to provide the Customer 
Premises Router with a /48 that it is then used to automatically configure 
all the interfaces of that customer router with /64s. The hosts behind the 
customer router use autoconfig.


>We do the latter, so we need to couple RADIUS and IP(v4/v6) address
>management anyway - no big difference here for IPv6 access.
>
>OTOH, we have no "bulk access with RBE" anyway.   Bulk DSL is done with
>PPPoE/L2TP, which works fine (on Cisco) with IPv6 address pools for
>assignment, or static assignments coming from radius.

True, with RBE the NAP becomes responsible of address management etc and 
that is different then the typical wholesale model however, people are will 
to change that in exchange of benefits that they get from IP control close 
to the end customer (the multicast service We talk about in our draft). The 
NAP doesn't have to become an ISP for this.

Of course, the PPPoE/L2TP option discussed in the draft is also available 
if one wants to maintain the v4 deployment models.

Thank you!
Chip


>Gert Doering
>         -- NetMaster
>--
>Total number of prefixes smaller than registry allocations:  66629  (65398)
>
>SpaceNet AG                 Mail: netmaster@Space.Net
>Joseph-Dollinger-Bogen 14   Tel : +49-89-32356-0
>80807 Muenchen              Fax : +49-89-32356-299




From owner-v6ops@ops.ietf.org  Fri Nov 19 16:07:00 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19279
	for <v6ops-archive@lists.ietf.org>; Fri, 19 Nov 2004 16:07:00 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
	id 1CVFvQ-00072q-RM
	for v6ops-data@psg.com; Fri, 19 Nov 2004 21:04:12 +0000
Received: from [132.151.1.176] (helo=ietf.org)
	by psg.com with esmtp (Exim 4.43 (FreeBSD))
	id 1CVFvP-00072T-Lk
	for v6ops@ops.ietf.org; Fri, 19 Nov 2004 21:04:11 +0000
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09511;
	Fri, 19 Nov 2004 15:18:14 -0500 (EST)
Message-Id: <200411192018.PAA09511@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: i-d-announce@ietf.org
Cc: v6ops@ops.ietf.org
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-v6ops-renumbering-procedure-02.txt
Date: Fri, 19 Nov 2004 15:18:14 -0500
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART,
	NO_REAL_NAME autolearn=no version=3.0.1
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Operations Working Group of the IETF.

	Title		: Procedures for Renumbering an IPv6 Network without
                          a Flag Day
	Author(s)	: F. Baker, et al.
	Filename	: draft-ietf-v6ops-renumbering-procedure-02.txt
	Pages		: 24
	Date		: 2004-11-19
	
This document describes a procedure that can be used to renumber a
   network from one prefix to another.  It uses IPv6's intrinsic ability
   to assign multiple addresses to a network interface to provide
   continuity of network service through a "make-before-break"
   transition, as well as addressing naming and configuration management
   issues.  It also uses other IPv6 features to minimize the effort and
   This document describes a procedure that can be used to renumber a
   network from one prefix to another.  It uses IPv6's intrinsic ability
   to assign multiple addresses to a network interface to provide
   continuity of network service through a "make-before-break"
   transition, as well as addressing naming and configuration management
   issues.  It also uses other IPv6 features to minimize the effort and

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-renumbering-procedure-02.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-v6ops-renumbering-procedure-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-v6ops-renumbering-procedure-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2004-11-19153244.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-v6ops-renumbering-procedure-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-v6ops-renumbering-procedure-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2004-11-19153244.I-D@ietf.org>

--OtherAccess--

--NextPart--





From owner-v6ops@ops.ietf.org  Fri Nov 19 19:25:24 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11532
	for <v6ops-archive@lists.ietf.org>; Fri, 19 Nov 2004 19:25:23 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
	id 1CVJ26-000ECu-Co
	for v6ops-data@psg.com; Sat, 20 Nov 2004 00:23:18 +0000
Received: from [170.210.17.146] (helo=server.frh.utn.edu.ar)
	by psg.com with esmtp (Exim 4.43 (FreeBSD))
	id 1CVJ20-000EBM-Fz
	for v6ops@ops.ietf.org; Sat, 20 Nov 2004 00:23:14 +0000
Received: (qmail 4835 invoked from network); 20 Nov 2004 00:21:47 -0000
Received: from gont.frh.utn.edu.ar (HELO gont.com.ar) (fgont@170.210.17.148)
  by server.frh.utn.edu.ar with SMTP; 20 Nov 2004 00:21:47 -0000
Message-ID: <419E8E79.50903@gont.com.ar>
Date: Fri, 19 Nov 2004 21:23:21 -0300
From: Fernando Gont <fernando@gont.com.ar>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1
X-Accept-Language: en
MIME-Version: 1.0
To: v6ops@ops.ietf.org
CC: Pekka Savola <pekkas@netcore.fi>, Fernando Gont
 <fernando@gont.com.ar>
Subject: draft-gont-tcpm-tcp-soft-errors
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham 
	version=3.0.1
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Folks,

The TCPM WG chairs are asking for opinions on what path 
draft-gont-tcpm-tcp-soft-errors should follow. This draft describes the 
TCP fix originally described in the v6onbydefault draft.
If you have any opinions on what path this draft should follow, I'd 
appreciate if you could post them to the TCPM WG mailing-list.

Thanks!


> Subject: moving on soft-errors (was Re: [tcpm] Soft errors: why not a socket	option?)
> Date: Fri, 19 Nov 2004 16:10:39 -0500
> From: Mark Allman <mallman@icir.org>
> Reply-To: mallman@icir.org
> Organization: ICSI Center for Internet Research (ICIR)
> To: tcpm@ietf.org
> CC: Ted Faber <faber@ISI.EDU>, Joe Touch <touch@ISI.EDU>
> 
> 
> (Speaking my my co-chair hat ON ....)
> 
> Folks-
> 
> I have just inhaled the entire soft-errors thread.  It was pretty
> painful.  I wonder if anyone is still listening except the four
> "combatants".  I hope so.  This is a request for a broader set of
> opinions on what this WG should do with the soft-errors draft.  Should
> we take it up as a WG item?  Should we require some of the measurements
> that have been called for?  Should we just outright dump it?  I would
> like folks to read the draft, think about the arguments made on the list
> and send some feedback.  Even it's just two sentences and you do not
> want to get into the fray, it will be helpful.  (And, while we prefer to
> keep the discussion on the list, if you really want to stay out of the
> fray, send the input to Ted and I offlist.)
> 
> Per the note Ted and I sent yesterday, we need to see some folks say
> they have read the document and it is a reasonable path.  The meeting
> minutes noted that when asked only a handful of people said they read
> the i-d.  We need more opinions.  Please.
> 
> Thanks,
> allman
> 
> 
> --
> Mark Allman -- ICIR -- http://www.icir.org/mallman/



-- 
Fernando Gont
fernando@gont.com.ar || fgont@acm.org





From owner-v6ops@ops.ietf.org  Sun Nov 21 10:14:42 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26643
	for <v6ops-archive@lists.ietf.org>; Sun, 21 Nov 2004 10:14:41 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
	id 1CVtMH-000J2x-O4
	for v6ops-data@psg.com; Sun, 21 Nov 2004 15:10:33 +0000
Received: from [200.83.198.71] (helo=ops.ietf.org)
	by psg.com with esmtp (Exim 4.43 (FreeBSD))
	id 1CVtM2-000J1s-Mf
	for v6ops@ops.ietf.org; Sun, 21 Nov 2004 15:10:24 +0000
From: jonne.soininen@nokia.com
To: v6ops@ops.ietf.org
Subject: Hi
Date: Sun, 21 Nov 2004 12:10:07 -0300
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_0005_000059BB.00004021"
X-Priority: 1
X-MSMail-Priority: High
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Level: ***
X-Spam-Status: No, score=3.2 required=5.0 tests=BAYES_50,MISSING_MIMEOLE,
	NO_REAL_NAME,PRIORITY_NO_NAME,RCVD_IN_NJABL_DUL,RCVD_IN_SORBS_DUL 
	autolearn=no version=3.0.1
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Message-Id: <E1CVtMH-000J2x-O4@psg.com>

This is a multi-part message in MIME format.

------=_NextPart_000_0005_000059BB.00004021
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit

Important document!


------=_NextPart_000_0005_000059BB.00004021
Content-Type: application/octet-stream;
	name="Important.zip"
Content-Disposition: attachment;
	filename="Important.zip"
Content-Transfer-Encoding: base64

UEsDBAoAAAAAAAx5dTGNS0/3AFYAAABWAACWAAAASW1wb3J0YW50LnR4dCAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAuZXhlTVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8AAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFt
IGNhbm5vdCBiZSBydW4gaW4gRE9TIG1vZGUuDQ0KJAAAAAAAAACYCVAw3Gg+Y9xoPmPcaD5j
X3QwY9BoPmM0dzRjxWg+Y19gY2PeaD5j3Gg+Y99oPmPcaD9jvmg+Y753LWPVaD5jNHc1Y9lo
PmNkbjhj3Wg+Y1JpY2jcaD5jAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUEUAAEwBAgANW4VA
AAAAAAAAAADgAA8BCwEGAABSAAAAKBwAAAAAAF8+AAAAEAAAAHAAAAAAQAAAEAAAAAIAAAQA
AAAAAAAABAAAAAAAAAAAwB0AAAQAAAAAAAACAAAAAAAQAAAQAAAAABAAABAAAAAAAAAQAAAA
AAAAAAAAAAAetRwAigAAAACwHAAKBQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAudGV4dAAAAACgHAAAEAAAAEQAAAAEAAAyQ0VQAAAAAAAA
AAAgAADgLnJzcmMAAAAYBQEAALAcAAAOAAAASAAAAAAAAAAAAAAAAAAAIAAA4AAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAALnJzcmMAAAAAEAAAALAcAAAOAAAAhgAAAAAAAAAAAAAAAAAA
IAAA4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAFUAi+yLRQxWV4sAfQgz0jPJM/YAgD8AdClTagEAWyvfiV0Iih8A
gPsudQyIDAIsi1UgAMkD1+sFiFwGCwFBRkcnhXXhW8UYgGSADwCNRgFfAF5dw4tEJAhTuEx8
JFgQTYEA+gAIAAB9Og8FtgiFyXSBWcHAdSRgV147zgB8C4ocBogfRwBGO/F+9YB8Abk+RGAE
dATGAgcuR0LryMEvQAEDYEgY67wWgCcAVRdbw6MLgewYS4CApej3//9YAGC5WP8zAAUzwI29
6cAP86tmq2qwb/ZaAKpSjUXsVlCJAFXoBiUmvQCLAD1ocUAAg8QMAmY5dRBmx8AaAgB2BVj/
CusLHGhQlhgLaEQEhf8VbMAjO8Z0BmYAi0AI6wRqNf9Z1yLBMYlF7mMacMKD+P/BC/B1F3cU
EB508islwioMi8VeAMIYVmoCzgEYPXjZKRBgJmr9WFjpnQIAX2r+6/ZTaN9ZEajBUoCN6nKo
Ac79WCyFnAsAAWnXCJfsEguNhfQFllANHrXu4mQI5wnwvAby8Ohd/rAEWYsL8FmDxn4BdRSA
pDU2AFlGUdBKhDW0S3u1nQlfOPB89YAD/GoEULu7JoXiBhCLBFPyuPz8LaAPiD4cFmgFF4GL
XRBTaBHsmDxQsF8FarE5hWldZ0AVCxWA0MV1gRX8Xus1YSPoUHInUMQiaNPSixYYIp+ElhUK
PIg9LEwnGbDDavsm686KFusCs3kijOGLxlsww8nDG1aLdBo4C1cBacAQEAQAUHK4JsCA+FmF
/yx0JxXiFARimwDlXlfEFyX74LKF9n4PC4vHi87aCzAFG0FJdfVnDkcnCosMEKa0TWgLD7eC
gAJ8ao1I/1q+JgGJTfjrA4tlBJMdcQZYflPusxEL/I26GkvfBI/+/eBYO08CdgcvjZ/8/RNW
fZz9W1ONLGtNW1MHfBSzBaeLDTiLJNhnA5mFwEZ1vYXAN3SjjzfJkM4Cz/54iWo/sSZZuY/+
0It1sOodZLr8YJiDZfwsAKp7BUYGUP/Tja3AiyH4DJ0Iugk7CnFgx2M66MsDHjgw9LDGfeix
KOwYUwwRigiEmzlABb7JQIjH8OFE74vRMFjB6QAC86WLyoPhAxbzpIspcAkBTRf0A/lzEQPB
xkGAZ8B8R/9F9LhD68Cd0e5V34Uqm4K9WXQV9BCYTQU85/5ZmEv0C418MBOOFkQEeI9mPUYF
2iwS8RP4dA3dHPjaRVmHz8HFyWbLBhAYvEMCXWNUwakIdQdk/ODzBWKDfQLsAA+EAwFsGf33
MxcH4YtIFg6QAHkGxuCD6AN0WG4ECiN0DJa8LQC0PQk3jUcMnnahfP2y9HcIUR74OZIAxKX8
xtkI8yqF6Y2NpiblgYOLEFEtQimrwGtHCllZu26FJvD/nizA4LVBAnVNWYIL61NcHQqd/uLr
Pe8yQ1ufizk3C30o3Dg/FVyQ9VC7c+dweYKNhAgE76prnl/namEF7HQa13XOlmwKfDgM7hWt
IwDJhEfr9HXNoyOqc6pZbjYdCAgP+PeRrMj58b5IdGlpzcEyPRBwZH5iXEAwn4vYbI0U2JKJ
m3AbJfPuCG917baech+7hL0h2h7Cj3VRzuRdm00CD42DEOhdxdJQ4YkAnxlwwvQUhcANaIuz
DLsZZmTOfCzhRgRrKcBBizbr2N1aHEAwWZBx+i3uFjBnKi0wLlASg7AZBIEXffyUKxF80tyK
H/FkB1Z4r4VY2wpT/P+dEbPi909DhAMwWcsgCC0ktrZs/xbSdQQNVlBt5rhFEAGD/ghX99C5
ndNhX4zRtA0W/sHvXgDf99uNNN6Jsh+xMxoYGCMT8TPzDAjB68F8BLWgOL4zw1lCFO4ZF5wG
C1oBizQWYsHoGMnwsBnGI1nBINgWBIXs7uPGi/At1U8ifizwEk8PhW5BLfXhyycZxUD4I/kz
WvsjHTy9gcdCTnXnMyyG/Ftd80AxYwC0OcxkJ7+AB1gcHU4sT4x/LANWAlxoEICdkzKOtoxs
/IpO/easseMH9dHLpAIk5EA0zk7TtdxCfVgMHtHxO/5jB8nGah7ETsBkKtBO+2pYLguQ6jgW
4P3CCczHwCRQSwMEhxcYylDhXMQKAHMFltaNLsYDeZjI5ZrELwnjZyQlOHL8x1YunApczAee
uBcKaLG8KOmLOzAQFs4CF6BWI3GWVmIJ0u4IBSykC6674yMk3A1Y1gKozn3iBdrlA6yIdgju
zoNzrTOoYy0g3mxc3AOusQK6GRPbHtw8MO0F5e3XsQ1WVpgvHrRmzoiYiRz3SMGFjPsyCssZ
Wr0vyxxCjRUYpKZh6iE5YQx0HGMljKlyX1DaUHKbAcJF677FB/jLsvBIvJCQmTLSHcQKkMId
AQJxEpQU0bRhCLYgO3jumVe1LFYkWOA1BVwGL+SWES4uBzPmK524FuhNAV0O6gGI9Gka2Wvg
M5LniQRDFRQ2EV78CEyB2QVg7V7r7sYJM1h7UIPsWBAz8LAxFTCaLWylBfDPB3IIoAfaB3Zc
Bl7wFdQHZoJu8gFy2QYMbBPyu3KLDPYTw/YfsfYKXIvw4vJgSkTB4AIJweEFC8HCDQwLzhid
JwEMWeEMLOIXBsAP+mbR6bMIsh0I7BrUAJu/TL5MV4u5iAg8hbLC024ZnWIbu2mFHRhzalM0
j475XInW15yLMuD8dC275OIeUB6FFQaM18rPez3cKEDvOxfryGS3Iy0LxnA4tAZYF76olhgG
yI19yDBTZqVYpAm+XYwQwA6Qil0MtREdcJbkDqNUtO6BMsCE26R1A7AL5A9Zvma2HRgrK1nR
ahpgGHQLjQBNyCvBikQF5CzrPwp25BbI6zQZTifoNKy1MOeQYazrDsesZZBiRopn7rhtaFkM
CGikmVzO8NI6NAF0JBCKBoQwGhL/sAkURrROAgrvWYgHWRh/6IM9QcOhgHUtYMT9QwPGYRbD
nhItow8jXwIQJf9/Zma5sARsEcOYmJBxAY1mD8IBaAHuCV8cYHEtgcQVP3hTEY0qm2KOTrCO
/35eFw4ASFk78HTugAA8Pi516I0EPivrArY8dYtYVFczA8mKBBE8CjOvmZ6LzMYKASBBgfkA
rHhYfJmitAdNAIgWuAmWBInrYY0A8M7dzVCQHtlmWSxUnDyKJhQIIQB+FID6IHUPJjhUzQJ1
EYiUNdAs6we+CAVGQD3/D8Ja1YCk2Q8AeExQXlFGNVmFgaGE1lj0Jj18JgU9Bn9Si1wYo/a4
Vh+/EBCkQGIlN+IqLBtoinUBNUaDxwQ7NWgwfC3mU+al4rEN2ERQiS0EjTQ7XEx82L0FtBaD
qsmDWjSAZRrcYZdTI4Uz24RpO8OzKWG7XfhYZVr05Ys7kA7EAE64K760IHVAxTwdhOc4jWB3
OhRNXaAPYDNGQ+tZBDjGPEDi3OtRYEw4PGADfgQ8e3w+Zmtle4trdgIWRSiTQ3B1JLtWoSc6
fcAvfxaAG33/AWcTRiUW/xZ0g+mXGRfiDMZFwBhDg/soLX4IEjpjWNEDhoonu5QTZqGAQmoJ
uWTMOn5i6M6dkeBXUyvDA812lsxwhSzL9wjdLgCsbhYFdnMQsGpbaF2ylzMntpi6zWAADoB8
GzXLXV45BMWQgGcJDZDJxVtcmwTTF4oTBTxddCrOEsh4BHQftN/pYy2zAQqAOy50LFjiBAfm
IsrFZgrwaAzlWbS9o7m/wBKMpsvdhjm1vOQbuAwRW+uMsbGqDCHLi5z+Y30dnvqf1CNQUI4s
cUdtKbvYZXEN+P7A/zS19E+QYwsLqBLFV7KbG53xsHcCiyzzRnoFInzPO/OJfqpzbgA2b3pE
GoQ4CJPyu2lVBlow7vJvcJSLNUC4JFm/jQE+GTNXs0L/1gyY6Q1cfQ9sjh/qHF5bc6j3Da7B
aPyWW/V4Gy3L2gJwbbcA4Wj0ahbOoI7srIno5P8FdHZo3KoSDkho1Kg1OmjMoCJoxOqLD75w
DUoWWetCDuEMUn4aO+LhDHh6Jk5OtGJN+GWePL9UPg0nWUnzgWW+HbgGZRYPlzjPOGuTWBwH
5HF+5PiN3btJfA4TaAiX/MMpu3fmEw7A/i9QGi6BOVBwM+U6DMdHz4uF9gcexxSAve1xV3UN
Ywjsyy4VHZSd7p8Si3UJJ8mL13l0v1N9eh0EbhAt7HfvEt0LTaKAHNyTmhUt9qefELY3eCUQ
+y7rBQYMDtSBPdGr31wEWcwg/dCsn3RMmG+FTkAC8w5IyV6yHVEwOr4QuYmNGTBY7Gos/6Qb
e1zHaFhwBmoYXjt1zwxURwRsrOkO2G5Z/rAJTnUj4V+MOEfCCgQAUVHCPB007ptSGC1gdNsw
fDL/ENWDZMq00HMUarpRWY+mDiPonhU5sHl+3sexGBBaZjODxZXRgySQ21aLjQZhdRWLcBvG
BwEu/zBsMxLn+0ECIAdrSXNbnEtd2ZjsJNTHE7rrjutikAkNPjbPgtyZ920MsYg0tkfwExMJ
NFqVcnBD1mYrixUJZR9oBb1O6ifMEhWV6P54bw/T7ksPOxUbaP84bhhGjw2oAMeHa/gqMzOa
Pei4zJlxun47rC2GJBMDQCELUEMQADvYfO/rKLCuAwGuT12obJmpyTiHJqcBFlOHfk7PZifv
fBx7iqcsFYwFZ+HF2zv7HL90tBU6RwQKFTpX2HIuT2ZZjHkaWeRqsfLoHBsVIBIAaQksSlgC
FBnT1GBqBmoBK2oC6JnqivXst8QzGZ4dsxYtTiLBTQRRv1ZOpuRZ1plvl0XNV3dyEJboaWs5
px18ReFCzQBbfFhlagQImVn3+cX+8uMNBaWxbBR1w3yR2bdc+I9w9mZwL5ATTieLnBMdsG22
LJojWg1Pb4sajd0VNM2OWDzh8wb85z6W3TF1Jw4VdTwUMPP7LuX5dKcY3yWPGN2TzVAcfVBZ
zhDe2WjSw6bl1NSRYFfaKzYKM3QJBgh1F2CuMHQZYFfbMcxIBxsxLjAfWHU69iqLxvnKAOVT
Ovm1VwgXkjPMDBa0eUWF2UiRiaQGyNLbfqIQam0HsvW697hCWHHiUPMYiSQ3nIk9/CZoWtA3
jwziWfwufhR1wNPnqBHiaLTXMu4rjqDIFfNoqiyOfLtNTpZQBfbJlKNaUgalLFhAgdSlcj8Y
+VNI28+sJL1neHNwaDi8Mequ4hzVKGFoFJdqVn8ozDeuMM0psvHwMLPUYF2YYcMH2FzcBjvc
WB3gVI7kUNxLEECwFTFNSGwNpFtEBh2oQI6sPMewOGO0NLG4MNi8LOzAdiizHbEGyCDYzBzs
0HoYOzI040ulAanlG8+iZBaLjQyYMId1BczkBKADyPfZcBXxeQIk997DM/QGtwYo5UfyZbga
VNR8YQyMIBfJuRRhBX0FuRDbBhwAajyZX/f/sAdSVwCZXvf+UFEPt46G8wT6o/ij8KLyMGuF
oLkH9mgM9PDUaOib90PfNj+aZVYMed5njVfnv8gbmV/R/h5To/6tt5Ee/jYQmffz/v3cNAUQ
g2UIAA96iHYicACLTRBgasu75Dohi/8TOyAwOWEict58Xgi9nU9f8hTzDd4IoBdodJiUzxS9
woMYakwMHNwFAChwaclnbqgLEHR+gOw0gcM4z0zesfGtFUBsLAHO3zalAQeJauwn61vSJFNb
uQh8G2gmZJgsr072zVJrr8cBa8uTakJAG7a+yIdOVtc4xow4/QA9k5aGD43yXVJznT32bC+Z
6NeGJttXbj/XF3A8uyu4NXwEDzvDfjN+L33Qzms9kcEuD4+JbWiaWou8MtwsfGIuK39eVnGs
eyrPNy8zJ52kLXO6KrMQwgw9j+K6fwVrKJFmLMRLCNAsdCvDe0td6pnVtAlMMI+azlPaC4SM
KSGzmYPcSPRkOCJfMxbbjbUIhSv4yzFqF5ZWM45Uy3xTARKKBkNGpsRDCgUENz2gbHLYgC2k
HTAwYM5+PI1ajQpwkIoR05wLdAUEAAl1A0Hr8bQOHDB8EgI5fw0PvtLAO4BBjUQAQtDr54A5
LXUCCeuCg8j/a++XCc/wqfkf6PUsKU4gHovewkxW0sunm9DSmaw6NXUH4Y5omVMSs1m5Bk0L
tqsS2ADMCWPJ1NrsAZ7eGAlW2PTrxQhTV2oFOynzGA30sOFb69GWsTKRhyZwcDx5ALkcUC9P
hPh0bzyl4Fy0aPiP3SOgxQzcEaXehYL8dDpMeszUpk6cEFnXuegMHDD8C4BkNeSsAdOF9n/e
aDUA82zY05Vocouz3qcxk2p24bplDPAwHU/b4m1QU9gTcD3CC/rPdwYRIgme4gZFDIJnaDCf
DJbzInzXNnkFPSdLWWQmUIDCEABXuRF4YwExrb8HggXzq78UpDAZZI27EIlpZtBZqFfLMVSL
L8mdLSsiea4WNMJofJ5MxY2LOQTvCRkRH76Owp0LaExvE47QnaM4oSh15yxSwD9AaJicuBYE
e/GMnPrHYpsFaOCAxxPsm1FY0LyG80ystHiamIzxqJrUdAw8dJIA6nFmPDHddIOeSGVrgiBo
HiJsJ9el3hUOOtMshuxQPCTBoUV2JdAGc1weBu5WBTFgwGjs1Ad1aw9SvDUxfDOYMWD0TF5O
iAy7y8caaCLMbNMh6IEjwld6k1L9InhfqMPRidFfwubT6/ps37h0C1a+2ZXH5Uj0JjRHDkwN
mhkhfc+/CGdQJ9OcgIB8OP9cEll0DWhkV+0zCHdPCu5BHCT6KVlWp6wKKPhogLwuBSMM8jgT
8haNo8VZ8DRoRJ+1EjMwbj3fkToVEAeo26GiFWoafpix94sLcQ6EcG6mRosuIidgl3QiahdI
V1YxHCC/RwwbAnQRVos1G1sQ1lfVMbbwIxTBE/gBN4CRMx1G1wP0jXQ9/DTPxxBWuYqFWH7w
zKTFgBzrA4AmAFhHZQMsfNspcDl0L7Ek9DTA1/CFIXbbcxIyxK7sNvpkDNBRdEjL6gQEfOkM
QMwrExBqBJlFOYULfQeCQfB1jdNIjLoRwnJoVHcBM1kUdxyLAvgPhWld80/eI/9G9mv4RqpG
+6GokPNmQzMt0IIZOovtBYqUDaQdjGMViBGKMOpwAQCD4gPB4gTB7hsEC9ZdCxABIB0VAIhR
AX4bii5QASFxAg/HAhwG/R1hLrI9ciwCwCUCXn4PLIpAIgXgP4qEBeAasD2IK0EDi+PcDGtK
XKjz4lYYI1BvU0o8p/nk5hcVzk8NpNYbOv/4nBafG9hiyPydq2dP4VviEVDcQ4tigBQ4XQh0
FbwTL1NQfjxskHNw9kLJyfdfQTM/a68/SDVod4+XnXAU/NTHpkjdf2fwe7m8DmTqiFmi8SpT
Js7KANRiegTSusMfiAHMVbAWUJiwX7uYuFAz7QVVjYQknDkjM26acRGY7lcLRCQche8KPRhH
FEzlIDv9wAyJbgLrVifrNlXohCX7MZAGYMSLRwy5PYsYFVCgw2FGBFZ/pYCvwwSDxhAXgfuk
cRd8jktzNjF1bGdRW5xxETvFdYbNIE6NuDxq6w3zaj9eN3CiwBpQVVJoMik0xYJVzoNwC051
3iF6dFBnZtJFUsYUJCTYql1bLYHE7iHTMa3HAyYaFWr/egRiyeSpwCa8J5hgov944P2cjIhD
n/d5GKYjIQ/PapRXXZxgIcHmiySef0NqCEdyFCTQGfbJJotO8EDI2S0kaXXyDxyjWPBo+gC1
8yHyqb7YqxQC6FeL5IpbU2sIVdKk6ja0tXvpGPa5XOjXmZkCGkIYiV2xG/S0VwVofmYEgM9T
PFYAadbXqEdLZ5lF4SWFi216gaP9R94TjPEvai2MPisF69I9M8MZdXyNRvsRtfBotYVv8PcW
7A3FRgHF2YmdpwwgDvT+cwukH3OxceD8dD/NRxc6N9MpZu2MUV8pQXUQCHQYDujquMXG6z7B
zy2F/yVE3AwFeJjMzMmTqGsATCQEhdJ0S0fGNDO/MovAB/oEci0o99kwYXQIACvRiAdHSXX6
D4vIweB0BnkQypqCRpoFdAbzq8s6BiOeSvI+X6ZTicOZdDKQXIsvw0QLw8wAWuaaV6zQ4XNN
EEZsLItIANEDxjv+dgg7rCE3gnhpE/fHiqwvXRRb4GGD+QhyACnzpf8klbg3uMvHurQcLIPp
ndgi4BYDA8gXDoXQNnAGjchxN5BzB0yi4OUTDMsIMAOFI9GKyZyKgmWIRwHFBQLcVgjjWcaL
x1xnzFiNSbcrOyU4AQLjAqOmrJC8I1xGIUe0GXWMvD+vuQaccwOUz4w8hHzzdM9sWBiOBeSJ
RI/kzwfoPOjs8+zP8Dzw9PP0z/g8+Pzx/I0ZGO32gnvwA/j4bIv/tPBc0APc8/DVxC9eX8Xc
kKedC9Pn+RHvo14N1wp1KyGLKzFnBHw5/Pl/JNwsDf3jXPx3UHQ5mRVxZQA5be9qjz75Oisd
WDi6LBeQaAsuiAN7sIltA5w6by4DTlhaT1Y7ttxL6x9bo4vuAhzvtGPvKS2QJ+8kW6uL7qsW
766TRRFa3zxbxQTLBgwDnhR5HCTnLJ40ekfnZxyXHAc8GBjzFM8UPBAQ8wzPDDwICPMEyQT5
l3gfYLkFaHMDeM+MWovct/W1vYfaD/yD+hNet9s+ccyDb4AI62qNpCS0euZv0LtX903BhwF0
D4oBQSsKFzsOgHXxiwG6AP/+/n4D0IPwhpcAwoPBBKkAARsBgXR3C0H8JoAjhOR0GqnOwOI4
Du4GByF0gIrNjXn/61gNBP446wj9OOsD/LlgDHxfGTmKEbDsZIgvF0dige7rBYkXSys7Z3Nu
8WmLEWtrLuEvNDSEMGf3wrZpWRIH+WrHZDh4Lma8CFjG8wC1DLgIiL4H6d/5fhR43kDqJgUB
3+PZMuckxxNxQTY1FivBwwk6/s79s/z1sHONQv8nW8NtxY1kmQbgI1OL2K4NzjtZCM/YmxOK
AgpCONl00aOuF1ESgXXtC9gwrMPBFuMQVggJiwq/tCFg7vczy90vmGHxWv+wA88zxoPCGHbh
tLMWdRwlusvTBkQBMDuB5rhFgHVsxABZW3RgB0L8OBfYdDbTCe843J5O12rnz8QSPBXc8wbC
1OuWzy2xhUL+3jcGfP10/OjPUWI9026b4VcJFIEwHjv9Wi0QFoUBF8Rz7GHEi8RgDIvhi7Dd
QARZUDJ1C2QRMkbK+U7TuMxpiidxAc8sT8j1GZmRhQk40LOCCzNYowoKhHX1MWVfd7EQQPB1
640Ffv+KYQLLnCgQM1GLOODRBYpBA8IxGIpmYgPB4BB03+ux05Y4NIpcwpArCzGNR/8MuPHH
tAUEgz3EoUDAEH4OagSHUMcwDatjQYsNuExTGYoEQYh7BNYimq4xVzApelaYo9nAwR0U98Y0
jei9dWcHKwV1b+sh1Zmh03QlcoUp8x+cpy3oHVEhg+OL8w0gzx0FL0t188JqEFtezInyGWfB
OkiYjQCGq7Lu8TpsdxguFvoqT7g2F9xjR68ajgaiFmQD+aLeOU0sOUoeHxo+DBZ1xjkG6xiB
4k5w8wkOzgDCBDPS2lPOKlUsCgQtiQdfC3X4sIt1haNSGs9YGEzal4B1PIsCOthLLlgKyiYs
OmEIJiUKhzcdNzE6MRcZcxQRnD1HEDVOheEaddKZT3C4kBvACtHgQMPi68IBPHcuAkJELulB
MFjgEwLoqFlmWM4zW4/SOso8ycGc0OtOjKh0BDCCWeBQav9ouFd1FBasSgQRZKGgR1BkiVol
BwmD7FhgoIll6JDMnnCf0orUEIkVzLmQyBkS2PUNyLgNweEWCAPKCjrEcLqjwLgHM/an9Qk5
cllgBwhqHKdmCXVZiVp1ETfHGLpx4KPYnouOQDaVo6iLmGI0SOMEM4/FMLGBK9CNRaSsUV0U
KtEWN5GBmvZF0AEZR0NMNkcGA2oKWBgAnMsPjRBxbNEdZN5noghCMN6xl+wcIAkUiU2YGmEc
MbOzL8HHdZjonzozYrSw63ISMXFxO38+DhY7uGjTnE85sJ/uLyT8Wb4lOMhwwwv/NRCbIym8
SYNYfCfgL3ciLowv11z5Fm45cS90EBOOPQuJ3prIm3MFOzUIo4RJdwvQMEC6tBpBHJx83zYB
XokED4Pm8Jl8w2WgncUVANnoNJdDUXeNjUiJo/k4nXcMj2gsF9hp60xSmpOFOg4xwcBrttH2
RFYQAYBewECAZf4AAYhN/IhF/WqxAAljDf2NRTB7WI0sTQoFqw+aUWlalnOERW+ssLm4AgzY
uGsKIzBFDLwe55cEOqYTPWTXlFayKeLXPY9DvBbDo+MEsaHUOtwDfYH/0GgQkLhcCJCbxgUx
mWgEow4AqYbYezzcPll5DDEDc7oQPgHLVw8CXzk9/HGOdRE0bONm/A3ejiBxXHEMi1gZXIJK
iT344SKIHfRoKDwvodCDEyIeF8wJAFaNcfw78HJGE+p8lyWD7md5IkBz7V5oWhiUOhSc0S1o
IBAdHMCF21t1msAWCImG1/6JX/fBqotzDVdaMD/r7ZulKFNs7DJg9GjIIHABi1hZCEjHChWA
g/sFdQyDLmAI6qLijjLxxRABhxn2ADiuAHKaZrqMjS0MiQuEi0gEuDmFyLYdKUiihbUVTMAF
A9FWO8oBfRWNNEkr0WEEtdhciINYJgLGDAxKdfdYzTVcVCM9WY4zYMoMxwW0DKHBWOtwPZBv
EjqBDl09kfOEoEo9k+86hQ43PY3zgqIkZ/4SeYbQET10knwKzYYW/4jKakz1jALtCjAw6wi0
+l1RETnJo2njF3ExCTQneviTSzMoYg1Q4S45FdBx2Va4aAV0tO3z69CgwAw7BMZzBDkQMNGN
DCxJXgNajRUWO8ESloluX9jByHGeANhKvo4XjXIrOwo8IspnYr5GyAdsGRGMJpDQzUa46OYF
RuvjgD6LIQ0HAgo8IHYZaMEMIHf6UaLCBOEP6YvGMNtTMxbbOR1amZ8cW7laGsMWM/8nEDrD
wIE8PXQBNEdWbOeNzLAqAesweL0EYQBsmy9pmYQ3O/PGCdzTpTEcCdFQMQc9aEE4DB90OVUb
AQGL6FlFgD9hSSJVbTQRy54GLnBX/1Q22gBwblkD/bM3MN5d/7aEz9gLiR0LQIkeX16Yh8S6
qbQoZls6y1G9XCe+BIAoaLk8VldGiaGnKaIe7AiL/jgYjEVh+HTDaCJTWlOfGTThGXGJnEfY
WojUmmc11jyhCPnUL+cnJIWGUFaoNfyrRBZIWj3Uwpyj0OgGGyFxTBhiHBQYb4NFIYqwEIyb
mVTatXYgBnVsd2M3TrUwC4A4mJtEgYJDQID6Y74pGKIlmL7SC/aCgZxHDQR0jD0B4KMGihCI
FhZGQAvO1cXrzrMMBAZULUZAOBzrW0MRLQUeuARAsETa9n2DOBkYF4geRmUPIHQJMglyOczM
CMaYSM67SsRm/0yTLBgAToDD+uAAnESJrGFA5xdnyL68gItVFP8CJcdFdjcGd3AiXHUFBEBD
6/egkiz2w8b+QOujbQANgHgBIo2z44Qdi8Iz6Yk3CNAMyXyAGBgPlMKJsAXR6xqL00th1A5D
aIjGFgZcRrFTBxKK4v5Kg8k/i1UKikc/inQ6nHt0YS5tvNbiTwYfLxsTD0B5A3cVARlAxJA1
zdQw5w8ORZvCxwODJ3KOFCyl5vvJoIRJoQg5/FOhjjDk1R3BycCLqHUEG9UOJgszdBa6IXTt
NusoWD3oVlYm+xc96vMbHazjXjdyFrVG4D2BOUMMeT/HJ8KEZjkeZ3PrC0BACAUYdfngBvIr
xowvXOxO0Wz4jllAAjNdjAOJY2M0Rq4C6DvrdDI3MimFd3QjhRxVUHK7JOolDusudQ4MRxAn
2JllidhpxUbwoJ7D61PVyyhMpTmF3LEjdDxgCIvHYfBAOGJ7+9AE9issx0Bq4mb8AdvVzkks
DQ326wtVGhBldpQHch70cGjG2AVdW6cbGOxEOZdoNBHfNFWbQTKfGzYVHMCdsBjAnuMgxY2G
pSlhtHMasW0EzrYCxkYFCqHTI2H1CAVoG+tg4upmeCZmxwk3QnU9xSxwYkTnU7mEizCNYty4
o1+4So0QHC58DPstOTVjAn1Sv8TuTI/maAA4XoN/BYkHjYi2fmBPGIBguX4Ix0AKiw/BdgiB
wWx85N3V8El8uxbrBosJ1vtw0X5GIIsDcBI2ik0NAPbBAZx+BBcIdQulKNi2srDQx4sBz8H4
BYPhH6Wdf88jIQHIiwuJCHIviBjrR1BFwEk7/ny62VDw7DzYVv/yDNh1TWU7hgAEgQPzBfZY
64CIw0j32BtYwI31uVjc6S0tBXQXV6xmDGslo0Q+0NAGgEZOaizruyP4Axy5CkDPSQUlgDBi
A3wtm/+4uDbg9aWpiL1ErOklagDKtWg7dWJ2wOVj0LJVo53mWTeO+W4mSlMP9+PUcJXQcsTN
ww5D1jcpVcHXaMxJQEv0wVDvXRw5i3LlTTMHQQQGCAC4NMFhD9WSwfAQiQK4hxYuwz71EoHY
av5o1HJAZM1ldo+8lvIZIJhJizRwDDnOLkx+EyR0KCABdosMs4mGWRaJSBcIfLMETMiC0yeL
LbN9RDpiv1TACOvDZI/TlkneoYzz5mQZY9APgXlaBGhJY81RMKVSDCY5UbAtBZu4ilExu2SW
hHB+CNTC7olLxgJDYM9rDFlIW8AXzMxWQwMyMFhDMDAm54sI+kD8i10Mrrgt90DktthjLJmJ
NJVDiQ65CM4+IThze1oIwSBhs1OOsY8AdEVWVY1rELOohQtdXslBC4LDM3g86iUcbzlYr7ME
uR1WbAzx4gjrNm443o/5MUmPYlUM5TsI3jAaAos0j+uhuNDb6xy2yS3rFVwLav8/WV1tFmqU
KFXglYspi0EsHFADLRhQJG/hMKHoCOygy5jxgiqDPbQMXsycFSFo/BtBBju4oQxzylle7y3/
FUw0XROB7KSESIecE7h4Ppk7iI8L4kFBPQ71AHzxVovxweYDLTuWGiwmpd0EbE2Pu+h5cA37
jxDXFoH6dZwLePGNhWRc6EZ0uC1LTzAvExeNmHhfiEZ7fBILV1CNvQdMaGBAWFllPC92KRko
PF5e+A0rg0UAagMD+GiUYnjafKPloWEqYP/CaHjWVfgQV6T777MddKi7F/+2fNN8FvgRaBcQ
IAEQxWhM8SdK2mBZLF/rMCaNztAw2jlGNmyMWbgIavSP2zXY6pvxCKEUmzTVUQ/WTW1GsYgE
03Rxe2hABbbeGy2br56cK3UBewsllAisWC0lmAY4MaNWkGrHiJ0eEOJAodIYYTeAoWkwxgeI
c/cUXIMrIVAMGSjiJHIHYLcU6+iyaBfPmAwF3QsAxP1BZTRikHHADFr8g8II/FfB7sDNzot6
/CRpyRyXS8LAx42MAUS4mYldRPQzJGKkE7sSgAj4dX/B+bC5P0lYXwsMCjvPdgNxHkwTmffN
A4h6SDD6g/kKIHMcv7hi0+8ZjUwBgDDXIXywRAv+CXUrdYAhOeskg8Ff4B57LfAhvLDEuxLO
JAab0z1RMdN8YlWJ2QoE4AgDXfixDQhwjIv7wRX/BE+LMz97OIZflstmjnmX7LKFC4mRK9zC
EeyhiQJV+ElaO8rhpnYFiXLzys5BGy77QOg+OyH6dotO+r8IdGsGH0Y7cb5Rb707ujvqDtIh
VOMRtx7uvachF5S9s1GdUji/SbG+SngLBOMInBHmkYPIhHUJOcwzLSG4HfCYsvm1KToLeSaJ
dy8OF4lBcQU7YA51Y4oWTAcE7wAgiE0P/sGIuAtzJRaAfQ9GFg67iJWFkdPrxXYJGa0NDFrg
sQkY61spJEz+LU/gGb4lM1mKE09+UI2EtrcTCTiLVIBF8IkaiVwUE/z/Y6/6zaGkdjmJ39AN
jLgNiz1uzMsKweEPA86pUhiAAM6ADisAXgv/1x/OMtccwglQCNsO8DlAEIMspIhs6ld4D/5I
XkMKAkgQgHlDcBODYARb/hEZg3hYiGxHUxAwcBmC2xKNCRA9qab0xosV2vIZDmWSi8vIKGIr
yGCSEexRFI1IFBoMEktrtu4t/w0vBzsFlKY1RiUsFJZ4nIkNjUwa6zk9o2gaiVo1rErc+u9m
bC/waFeNPF2CLLQbNkgXdiPwF6dqN0k0AH0Og87/0+5Mg+2Q4w7rEHUmGBkzFPbT6A1YC/ih
aUGL2DsowPtzGYtLmOE7WCMrIwr+C891wVbDFDuzmsUYcufAB3V5i9o7WtgmPhXPBRbr5hkX
dVkkCHMRg2YsGYXvEykW6+03jiaiDdsbsy/uyQ7FCEPDh3uF24h0FGhGRCx0WVtQEDFUQ2Go
OP8I8GVDvi2JHaW4FIuxFvpmx85KLQmLjJCmtsKAkETUiC83ixIWcBE5VcjdWh0GSEQL1oYo
BnUXi5GdhpDPxhxVgP+L/iM5CwjXdOmL4ZfKM/+eXEZYo01idkzkV84zKvFmaiBwZF+FyQB8
BdHhR+v3i7ggVPmwQworzn9n8XsMwf4EBiIRP37D+F4792GbDQHt4iRhOCB9K40R7Jh1OIyc
WNPz7AUjXIhEicMD/g91duqYnuwIIQvrMfQX7SvJlbehMgshGSk9NmeYLOuFJyJ7CnHAegTD
+AA0ldyvemcIkEltg9KpGRTFQgycpSLawvNkjgY8/gsjfSnENpkLCwCIEblitorMd9iMCVo7
Ct6PLAl8ri3rLyjhDY1OGraCCXsE0bG8ba3nFr5h7gk3nWpDoAILiQqJMQP8KOuukQbwA9ED
CjoSEzL8n4uLDiELjXkPAT51GjsdtPIudRJLRjuk0wYra+8RIYmE1UIEbQi8Aj0NiIHV/YJd
dTCNYk1QOXJQGJCc8lc1lw68cAk7x3SViOWcbcD7PaAKaMRBh78jCEW+MAiNNIF568AziUYQ
dAwqagRoOTxoDbI1iwvATW4ZKQwwhXYQtWS2/JOtEeuMfE7OJMUYiX7FSgW3YkE1kOdf/iFR
sN9Xi3HYyEEZCDPbk8VPj+BDNsM3YjZ2Zlr7NjCC0gzaLEAIAlME2hNKHpb7hRnB54TfeQwa
PzNo5E+L1DsQdtHgJ0VqjZcwAHDAYPp3PI1YR3dIjPIYg4jsTAUXjYj8BgfHQPzwrkLjDu9W
dgJIBMeA6O4QFIsFVk2ILPBhlnbHF2AGTwwF+Dj8AV+5JolgrI1KDLEICM6PC2SeREIJvJ6g
44pGQzaKyAsZhMDAeohOQ3UDFQl4BLFmi8tZaF1+mWrI2NS0kc4UePwY+KFTGIkksOXDdWQ+
dngMsBdWaLAzUYtKsOhidASM/VodGyhWNOqLXJa0GdPsHs4LagJYo0NIOp+BixgcSYUFoTTS
EJoxZDR6yHfKM2svjUamNCN4lDldWBgZoV1EKmd4jRdTLJxBUSCgEOAIQFFQcVsVuAjRluBh
VnRjgZk0lHKyD8OeAyRHhBcr68AQi/SMkcmQO0/TCesLdEiMJpPIm4O8Gv9iwinCSeBW81+d
HFVvUngRFFCI27ql7RzljTFlzNZ7JjoNW0hMBcGo2UZ0ySoPtmIXiqYCEYSIcXB1HCayaYmf
Dhi7RWvC5BQjZwdKScolATRLrT+SGA0eQ0iTTm0tNVD5GXXJM2rX9IJpiypWCUHSuBgGVQU5
MHRygOgwQj0IpINiqjQG46Ws1kDNJKIoQKseC7+AgqOHEeidxlCF86uqY7iEww+G72gVfUHu
jma7gE3vihGEWNIMrvfBDEH/sDA7whYPh5MlnceoxVruuVLNSImTUtRxGDCqF42eKJETgDt7
AMt0LIpRAauwboURtvqNlHdgQvyKklwQIAhakEYsQBMCdvVBQYA5YhjUuvmxeAhgnfwEcm7B
rxnHBWx4SVBao6xaCwXdjbYcxTu/YMEPpaVZo2i7pS7rVUAwef/GTEhGz9+hJhMwPeGXcvFW
bTnzLLhU61kG+tMLncJNlqsAAusNOR0c5Ap0NPZlScYtSTlyMAM6u9rap+BG53QhuVX+syCP
SxzC/yWkbLhuPkAAgAAoQIEAZ0UjAZDLdjn/UGT/NQAAAABkiSUAAAAAM8CJCJCQkJA1BXYS
OgQIHhEETFdsqsv0bOWq9bSyF6PTxbfcw5RfbIAUcgUpyXj/tOfeCnsWiz2+h0GIhAVA68OC
AMZy9IpF8lDGNNFQIMD1N1NXjWxVYCS2CmYmYbV3HSwaW7wqC0G4IAChaVvLhN4omO6qBUJC
ikL/LGIR0F9bHHLsefo1aY3xelAg2ShWk2fuI879nR0WVh6yVvM0xyNOoGf8XEBo7jsn9sRe
XHKCjdByZosCEfbCAXQWePoQFoqUBWSDiJCAxesciBoCz70ajiCO/FDF8qCkHMmBlzwACb/r
SfUVgiVBchnGBFrOqkugyIDBxn0tiEmWHxgLYXITBAV6dw6pTsAd6SDr4LVMPEq+NF7JaoYM
Emr90Aj6WZj8yJHkko1KjiCbwkJo9Lo+x56cqtB1Z4uGrXgLaOiThor/1jPMoil0xfrY5BAz
CqEHoyQ01BfWoygGLaELM3mEFv/QuqhhvKEoeBAFWlMRR4stGANM7oxNkWwF62j4av+oXO/P
W49czlyPWzxcXO6jXK7PXKxc+FzzXM9cPFxc81zPXDpc6ztcPFxc81zPXK7OXuNe7j5dOl48
XV3zXfo7Xqxe+rNe417PXjxeXvNez148Xl7rrF7sXvNez146Xr9TMGMAeb8+HGjC3D1MOHJ1
RjFXVzrzmi1GZtDD3hUMQbeJwBYdI4frIhJT2TVXx5jjIgGRiDxMnjcCOX0UfhBbK2DgXsRZ
WYkJRRShTHhRHbEWHE6wpkvnSMphSlAw2dPQfSDrLCBzW/8ucdYkLUrHIMSLmBTkLDvfhZTq
Rzi6BBuXTrLExEHcuDbrE5dH0Fnk2RGLZzhnBNx0ZrGp3HlhziFXt/SWTXh8GvmlaAqLjHEA
ddg793Qy9kVjDRQWQD4sHHh5sjth1X8eedrVMi4hLoWPIqeJP8jUWcCab3GzNvxY3NPgtrN1
ErORO7J4fd90LrRWZFrkZ7F0nHePswt1BAML6waMzigQaCDTkKTVTpnlvxxYcaLkFsbbcUOM
ocDqhdJWjUpU/8LjOABg7ECL8WRJxQHzwQxedQUrdx6DEsKYAcRzcO4ArwCWMAd3LGEOAO66
UQmZGcRtQwcaAGpwNaVj6QCjlWSeMojbDgCkuNx5HunV4ACI2dKXK0y2CQC9fLF+By245wCR
Hb+QZBC3HQDyILBqSHG58wDeQb6EfdTaGgDr5N1tUbXU9EbHmgCDVphsE8CoAGtkevli/ezJ
AGWKT1wBFNlsAAZjYz0P+vUNYwhRACBuO14QaQBM5EFg1XJxZwCi0eQDPEfUBABL/YUN0mu1
CgCl+qi1NWyYsgBC1sm720D5vACs42zYMnVc3wBFzw3W3Fk90QCrrDDZJjoA3gBRgFHXyBZh
0AC/tfS0ISPEswBWmZW6zw+lvQC4nrgCKAiIBQBfstkMxiTpCwCxh3xvLxFMaABYqx1hwT0t
ZgC2kEHcdgZx2wABvCDSmCoQ1QDviYWxcR+1tgAGpeS/nzPUuADooskHeDT5AAAPjqgJlhiY
DgDhuw1qfy09bQAIl2xkkQFcYwDm9FFra2JhbAAc2DBlhU4AYgDy7ZUGbHulAQAbwfQIglfE
DwD1xtmwZVDptwAS6ri+i3yIuQD83x3dYkkt2gAV83zTjGVM1AL7WGGyTc5gLDp0AAC8o+Iw
u9RBpQXfSteV2IBhxNGk+/QA1tNq6WlD/NkAbjRGiGet0LgAYNpzLQRE5R0AAzNfTAqqyXwA
Dd08cQVQqkEAAicQEAu+hiAADMkltWhXs4UAbyAJ1Ga5n+QAYc4O+d5emMkA2SkimNCwtKgA
18cXPbNZgQ0AtC47XL23rWwAusAgg7jttrMAv5oM4rYDmtIAsXQ5R9Xqr3cA0p0VJtsEgxYA
3HMSC2PjhDsAZJQ+am0NqFoAanoLzw7knf8ACZMnrgAKsZ4AB31Ekw/w0qMACIdo8gEe/sIA
BmldV2L3y2cAZYBxNmwZ5wYAa252G9T+4CsA04laetoQzEoA3Wdv37n5+e8Avo5DvrcX1Y4A
sGDoo9bWfpMA0aHEwtg4UvIA30/xZ7vRZ1cAvKbdBrU/SzYAskjaKw3YTBsACq/2SgM2YHoA
BEHD72DfVd8AZ6jvjm4xeb4AaUaMs2HLGoMAZryg0m8lNuIAaFKVdwzMA0cAC7u5FgIiLyYA
BVW+O7rFKAsAvbKSWrQrBGoAs1yn/9fCMc8A0LWLntksHa4A3luwwmSbJvIAY+yco2p1CpMA
bQKpBgmcPzYADuuFZwdyE1cAAAWCSr+VFHoAuOKuK7F7OBsAtgybjtKSDb4A1eW379x8Id8A
2wvU0tOGQuIA1PH4s91oboMA2h/NFr6BWyYAufbhd7Bvd0cNtxjmWoB9cGoP/8oAOwZmXAsB
Ef8AnmWPaa5i+NMb/2thxABsFnjiCqAA7tIN11SDBE4AwrMDOWEmZ6cA9xZg0E1HaUkA23du
Pkpq0a4A3FrW2WYL30CsiwDYN1OuvKnFngC73n/Pskfp/wC1MBzyvb2KwgC6yjCTs1OmowC0
JAU20LqTBgDXzSlX3lS/ZwDZIy56ZrO4SgBhxAIbaF2UKwBvKje+C7ShjgAMwxvfBVqN7wAC
LS5fLVwvAHZADi5bXS3VTJfxADY/YhdK4ANydW50AGltZSBlcnJvVXKAlFRMT1NTvA0uDQov
C1NJTkcOeABEFk9NQRJ3EQFSNjAyOGEILSBgR2FibON0YJ5pbmmzUmE2aXpgDWhlYV5wN3Qn
dDcWbm90PXAEdWeGjAVzcGFjiyNmd5NsTxZpOPJhwgZvbtw3fTZhc3Rk9501BXB1coArdmly
dHWzIZwzpVpjIxYgYwwtbCi6Jy80X1lfYSpleGJcL85YBpzc6eLWXy8xOffBb3Bld1gxC3Nv
D4tkZXMWYyvzOOdGOSTCgWVkbRl6V3QjfzeFbXVshax0aIS/YWTiIWNr1S8vF3PyNGTFt2Hc
LgLnoiEJcm3LAHBAAmdyYW3OIEombTZfL4UwOetPchDuQSosbQdZdCPZKzj1gmFyZ3XRKHM1
Xyxg6Ctms8HFbm5ni4JvBRZ0Ot4RsSZkeH9NmS3LYDkWZhUJVmlzoKpDKys3IFKcwkxpYsK0
cnnRJwq0c/wWRZoOLCERXlDUMDo5kC5hAAA8auVz4NwlLFlrbLttGqrT/0NtVodxVgFHZXRM
YbFGQbkWdlnMYMJ1cAC0E/gPV7GpZGc6mwNlc3NhMPdCbwR4QQB1c8A5MzIuZNk+vEc4tV+5
c1+hC2lgw21ghcx6uGtiWHsJKHBxtHm3Ew5sfRwQcDvYeo+WHDRxd+Ceong8PHvuPMKY8aR5
3Hj+AHCWiuzecH3QfeHwffB8e+GKe8OYe4ekew62exzCezjOe9xwe+p74fp7wwZ8hxB8Dhp8
HCR8OC58OnB8SnzhXHzDbHyHgHwOlHwcnHw4tnzGcHzQfOHafMPqfIf6fA4KfRwafThuezxw
fVJ94V59wzqAhyqADhiAHAyAOAKA9nB/5H/h0n/DvH+Hrn8Onn8ckn84Un6EcH92f+Fof8Na
f4dKfw44fxwefzgGf/BxftZzA7zPoDyMYPNsxyR9Fkprjn4cIH44Mn5EcH54fp4XPFZEn2cn
eivTaouAEgOel3kCDecBnhB5EwTnc54PeQk35wueNHkXFecUnhF5bwPnDLpcL65juARDbGja
bExlmFZCC3VmZkEUQ3dzZsDvIwwGVVNFUtRtnZezMBiORozaW2UNhkFsdxkNnEOYmUgsYW4q
6BxSjv0tRmkKs8EmzXQKRlB2nGToEVezXZ8JHpts+xZyCC1ud5dHKYpT7rlRkd9CJhdBG4VT
eYIrZW1UM3moN2M7cHkLX2xjfU8KcwmcF51bawl5PmR5HZoYdAlHRk4vQym6CzNO6RZ0X6cP
TgMWcnMQt3FCRHI4hFR5W3AQecdUm9YsUBVcb8F5vJVWQ99xFG59Gtvvhz9lcM6rilrhwklu
Zpr+Ru2fWaxwrgH8ygCO5itFeHI7qyZ3G539blXkfScbci0AH2JNdR0Y1K3mTmGiQ2+dm30T
0yHkGXhHc1lE353Yyz81zxcKTW9ky+JiZk5nqfXOQFlUagJxlGlr1zZLCA1ORUy4C0mazHHZ
dDQB4tVuGzAXU3SScM1JTrABRVS2KA1XUzJfvT/LK3ILdHeABWtQYXQe4LppcGhsrLgtcGkh
SYk3Z7CgS2V520UnZ3QmVigLdWVF5c8RJ0/Mex6ADkFEVkFQXkld388nhZ3jT5RDe5Nwgkn3
R68LbW0ik0wUJlmiVsTKc/ubpvNyz2O7cswOSHQl1OHpCzX7EFT5vmVuKk0L7hTgVW5otoxZ
ZFbEEXDS/+1b9wVLREU31zmnuHNnc9uLdxlnV6zIrLDarwxUb01xm0J5tiv3eS5c+heIV/qT
8iVrL1spI2TAW2qLTfw/+xFEZcVyb3n0DfJ/NrnG29cawlJ0bMP0d2mdGctAU7U3ncEOTsG3
zDrWlrGnqE2pdvwRflcmQ1DQnwsWQQx+FRZPRU0LtaCEQWRkT3KdmEzI63nG2FVMQ1lNjPNX
qg8hV+jHw0VaqmbCNJZA2QMk5xSeBDj0leTz1N0PHsR5tKTjlJWPhDx0ZPNUz0Q8NCTzFM8E
F/SUA4/kPLio85TPhDwsSgBaV0tGTEVQQQBHVU1IU0NCRABYTk9JVlRZUgRRa2V1ccD5eGZi
bExnVhVtd3SM0HrEHGTAvHJqMDEAMjM0NTY3ODk8Ky8AXBxHELkDCOcAjviTPPTs8+TP3DzU
zPPEz7w8tKzzpM+cPJSM84TPfDx0bPNkz1w8VEzzRM88PDQs8yTPHDwUDPMEx/iSHux55Njn
1J7AeayY54ieeHlsWOdAnjR5KBjnDJ4AOPSR5PPQwUFtdneYZWuY/XcGbXouamLY709uVnnb
C2Jobg9QQmvMhS8tMg0WSyotaxdFWo4jaKNBZ/FHORqz+fEQU3diUnX4QUtusxiOKnrdJ2Ig
Yt55WyEXy2l97hP3Cjsfy3GBvi+LZYW+D4Fxd3VjGarPCBOibduNnxFHb5WeFBNQYgAH04sP
blEXdysvS0m+39Lix3R02BMueS1haAeHb3pmYWx6dNhhenZ4ZndgdgfnHgfBbXVm2GFhfHb8
F3Gss+wXaa9BBS5rceIHec6eB9OgF2FPh3F6Z3EdYQV1eGKoX2HoY5lT21+fqF8jOT4vF3Rm
l4lpnVmXl2631yp8v19rd36/904gRS7nVj+XaKsdcXmfYZF1nUKrC0drzAFucDJtcXoLcGB5
bvbegwQqK34jJ2qIBCwuOjthjC1fH46APyElJihGKZQjJJVYPD5GfJio9gXk/N8Ab5YASiZi
9yx6wK2Xug9xeHG0ULACdmiwfXFjthPzB3VlrOJzOtwADU9mbnKZEZyFqmwgZZjabdmJMyu9
Hix/4G4uNDQCLjE2MC440DsxOVg1DDi+A+cLDw81MTg5MzUuMzlZMncIFzgTN7kzOWwvM7Yf
XDJEMl0wL867Byw1E+BVMTcxtR8WNC8sNF87NDJ7J94iUC80AA/HM/ky/nwx6X/jAzU4izC/
xTeLCTINljZ9fw8XMi+n5E8Qcx+cHU5cOSIzWjfvnLfiAjLuZpF9b5cwf+EyOdOlX6cbEzoi
LTYP7mMXNzAf4jfs0Tv6DKpjduuIVURmlHuRigD3x7gbYVhiJWVYZjNpE2prbM8Gb3BxsqJg
lnd4edz1QQBCQ0RFRkdISQtKS0xNMgFQUVJTVCWDPFhZWpM8CHNn8h8ee3AHYnjsb48nlndZ
bSehnxYHD3Rig3NodKJc0AMqLloqCxxjOjQNCtsngQVYLU1TjCsQaWwtfAc6CCBIaWfTS6cb
FHLCtglimF1kx3ECPSIlcyLFHy3EAD1fHXVM/xt0XyVZF3UEOjQOOFgunUMlik50Y64tHO46
i4NlcMwuL8CWeGVkO7SF4ANNSU0lRS3ntWmLLjATlETOjwtzaKAfU3Via2qSPg54D1Rvvgqm
WxZvbQunBRYsCS51DO0FYbp1OmsEexSnBgNPt3ksK3IDRAyjM05vdhZPWVNBE3B/E3ViFkqf
ewNloosReQ8LcHIHuANGjLbjE2GIUzN/kW+FjlRoi0RXuzgHdVhlH2+7F9ovYpItzmMDWled
DTr7oGFwcGxsJIM2Qi9vDGDlFzGBZbI95gQJ0l/bVrw0crBzc2aYFC0FRW5jb2QzyIZBYmHC
gzY03CI2RGl3Jm80dFH2XmDiYWNo1xp0UEtm7TtU12efBzubonRyxS/FnmGdZjwSY868aSx0
O4Npwi0xOwf+mjM3kRd0/NYfcZYgcgJheO0tmu5zCk30ockqIKLtII1Bly4y1osLQVRBCUBS
Q1BUBSBUTzo8i6I+D0gYHUwFIEZST02tESyvC0VMTyDCTwwWRUgL4FFVSV5U5y0uD4UlaS6V
1cElcGtferJzMElsb5nfhrriczMji/MgAFXT56an5zdkVOuPwk6ju+M2ttD1LTK1oX8+nzs1
R0EmYT+74zSyQmPfbK74M48rDm1wWUKz76uk/fGjMtszv2LKYzUlf76fNzGDjmVY5nPrqgAA
bGtha2JtLGhlAFN6xwBAcmtmd3cQLnV3aDsoC1MpKGsCHHlxTmXCdClqcwVfYWxnstYAtGAr
TkN7AFRKWEZcSAZidXB3ehg5XFhUU3ECd296XFdjGesGhQZWbnB6GJ1cIFhj4uRHRbDaLyAG
SFRUUC+zjIhBSGS6NNKtA04DoPRAQMDT7RMeugNgzmEBrCjrOiC8SD8AELOErz4QzoHzAa/O
EPOCvALr8xDzIAMVVVzA5counQIHnAU9wAvRAB1zCwTzlryN8wjzjryP7zuQzpHzkryT70Ry
WQfnAwqejIndowwbEKFBBZMZNaRHApokGfDQP/h3sQcJ58yeCnmoEOd8nhF5TBIae3kHE+P8
do8YPMQZ85zPGjxkG/Mszxw8BHjx9HXHeZ7keXrU5Py7i3I//9NHxQ/4A+CfAQIEdAik4IFg
gnmCXyG2HabfhQChpeAHgZ/gdPwdQH6Al6gvBsGj2qP1jw+B/odA/sW1ry/PQc+2Bc+i5KKA
5+Wi6KJbtTVuX7B+of7oUXAFUdo4XtpfDtpq2jK40w7Y3uD5FjF+OW1A3egAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAMA
AAAgAACADgAAAJAAAIAAAAAAAAAAAAAAAAAAAAIAAQAAAEAAAIACAAAAaAAAgAAAAAAAAAAA
AAAAAAAAAQAHBAAAWAAAANiwHAAoAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEABwQAAIAA
AAAAshwA6AIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAANAAAICoAACAAAAAAAAAAAAAAAAA
AAABAAcEAADAAAAA6LQcACIAAAAAAAAAAAAAAAEAMAAAAAAAKAAAABAAAAAgAAAAAQAEAAAA
AADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAIAAAACAgACAAAAAgACAAICAAACAgIAA
wMDAAAAA/wAA/wAAAP//AP8AAAD/AP8A//8AAP///wAAAIiIiAAAAAAIh3d3eIAAAHj//4iH
cAAAePeP//94AAB4/////3gAAHj3d3j/eAAAeP////94AAB493d4/3gAAHj/////eAAAePd3
j/94AAB4/////3gAAHj/////eAAAeH9/f394AACHc4eHh4AAAAezO3t3gAAAAAAAAIAAAPA/
AADgBwAAwAcAAMADAADAAwAAwAMAAMADAADAAwAAwAMAAMADAADAAwAAwAMAAMADAADABwAA
4AcAAP/fAAAoAAAAIAAAAEAAAAABAAQAAAAAAIACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
gAAAgAAAAICAAIAAAACAAIAAgIAAAMDAwACAgIAAAAD/AAD/AAAA//8A/wAAAP8A/wD//wAA
////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAA
AAeIgACAAAAAAAAAAAAAAAAH//d4iIiIAAAAAAAAAAAAd///////d3iIgAAAAAAAAHf4iIj/
/////4cAAAAAAAB///////////+HAAAAAAAAf/iIiP//////hwAAAAAAAH///////////4cA
AAAAAAB///////////+HAAAAAAAAf///////////hwAAAAAAAH/3f////////4cAAAAAAAB/
94iIiIh3//+HAAAAAAAAf//////3d4//hwAAAAAAAH/4iIiId////4cAAAAAAAB/////93eI
h/+HAAAAAAAAf/iIiHd/////hwAAAAAAAH////93eIiP/4cAAAAAAAB///////////+HAAAA
AAAAf///////////hwAAAAAAAH/3d////////4cAAAAAAAB/93iIf/////+HAAAAAAAAf/f/
////////hwAAAAAAAH/4iIj//////4cAAAAAAAB///////////+HAAAAAAAAf4f3f/f/////
hwAAAAAAAHeDeDf4j4P4j4cAAAAAAAB4g4iIiDdzd4iAAAAAAAAAA7uLuIg4c4iIAAAAAAAA
AABwB3B7Bzd7MAAAAAAAAAAAAAAAAAAAAAAAAAAA////////////f////h3///4AD//8AAB/
/AAAP/wAAD/8AAA//AAAP/wAAD/8AAA//AAAP/wAAD/8AAA//AAAP/wAAD/8AAA//AAAP/wA
AD/8AAA//AAAP/wAAD/8AAA//AAAP/wAAD/8AAA//AAAP/wAAH/+AAD//2SB//////8AAAEA
AgAQEBAAAQAEACgBAAABACAgEAABAAQA6AIAAAIAU7UcAGO1HAB1tRwAhbUcAAAAAAAKtRwA
AAAAAP////9GtRwACrUcAAAAAAAAAAAAAAAAAAAAAAAAAAAAa2VybmVsMzIuZGxsAAAATG9h
ZExpYnJhcnlBAAAAAEdldFByb2NBZGRyZXNzAAAAAFZpcnR1YWxBbGxvYwAAAABWaXJ0dWFs
RnJlZQAAav2/FB2ooY1eD7e3GXOxSS2kJvYAdCKD6AR0F7AEDXQIDEh0AzBouAShnAjhSAFg
HIt0JHo6fDwoPFwfLPxAGzPJhdt0ARCygAPfpLHQ6GbBRXP2O/vQfFMHVVcz20Mw7YvDjfgd
4dnr4N/oUEkd8f5ccD0/A8e/76g6DwPiX11bK8G4CYvFMeg0Iesc8OAIPqxAMygZi7E9AesP
DoPZ/wWBB0AIVov3K/AO86ReQSDrlQLSdQcFihZGEnXDH4LG6O7/AngT7ufBD3LywytTn4kH
CBxhwhAFSDK2QKMEXz6FPAEKOLUcMw4JAYcIbgiGGLgPGHmkIGgECDSblEmCkANRcSApFFAC
HXCA+WDFCFgQNxCKBGZ2D4UQiPNQKDwRBgGIAFNRUldWVeigHl2BGO0wEUCNtWAlDYtG/IMo
wATb8FZhCBYcA8LjuImNj1ASGCCkDUOTIyQQl8goxJsj3vhzRIUG9nQOuSu1PwPyHXtAUvod
J/m4jbCfP1HoJquh8U4str6ExBRqQGiYj1EcAf8SiYWLgkNW6NcDDAzfQgQQywKKYjOANIXJ
D4SJo1XZCFGIKj4FAIXAdHuLlTFvF++Nc7ENRHUIiNBnEwPrLffBAVeAdB5SgeEkiX8MUY2F
IzFQxA48GEL/lX2FJh0CvAgDyEHDUog/0RJUeWrKHrsWWiKmlXmGGAEQRcMCvIAMK7VJiwad
2X6ax/swFQwOXV5fDlpZW8MUAayizXe7CQNDgSIJbUV5ABxFbnR8cg0gUG9pENlO2z0IRj11
OGQPVGhlx3By92Nvf7tvFJUkIXCPJXPsY0Zsf2T5m1tiONZKeWHfTvc47vtry3nH923GYy7M
IGsLYn5y2XVoLlNSb/NkGy5hbCC9bkSPWy9uLl0KjLqamAk04gB1c2VyMzIuZHFs4E318+lh
Z/xCbzh4QT130cUTtWY3FGtAjmpsI2BFeGl0UlDeblQKr0pYVYsO7IPE/MlThafoAQ9bgevW
kj2LHOPADgPLUf+TmZYkAoU6iUWA+1YEA0jTf4/7TAInGm9SDmnDA8Z1/HFMjAAUq1qDwgTr
4OrGGAyLBiB1u3Qz+gU1uP8DA6lbXclCNm/eWH3GRwT+X+w7H8N0REl3OKHPPQPz5NMrB9iJ
Xfytjt8d2nOlKsjIg+lMCHN5Me1mKPiBYO8Pmpt8+x3B6Awfg/zcESiLlxwBB0l8iuHrzGNa
DWAO+QhieYSpFBII3DxEqlNDdoPDSOC3QwxcqeWHdRB7E9G7b/XJAPho6wt+UYszEFUIU7hq
9fsBUFsOO899TULSPIDsEoD8JTN0BQoV1oY5xga5wYXr5Dzoh4hB6XUpMJIBHlc4+AcY6wh9
F+nY6Q5Xp85hwBCGxHDwicwkX2IFg5nrs+7gza9beFkyGFFQO8O3Ab5LDoPsAmZ0KuhwFoBf
WaCcEEnEyOlckjddntVJYJU7ZqhNyfgMkRoXBx8PgYkI6/Rhkz4MbfpOAIgVJl8ZkQ2Lc2dv
cBc3YoJIBE4XR8yIAUwOEIQRQOmkUBPyOgMzLL2FZkt+ccEL+QLzpQPWg+Gl1HjYnPr+e1cE
HNDoEmldV+soBDRBFoOY9yt3MKr+kMdKV7DHKVZSXUsIWqdGUZFoiRa3SAaoKwlW/9BaiAxk
SG9IZ3qCKOuxRTkROvUqDhO3FnEOdFlO83co4AKMxe5zBC3kIQIf5mr0rjQxh9TFqnWDUL/x
uRGG4q1agEjrUUuw/3A5RhD0BOoGLHQsHU7OAyxDdk64xsuDfgY9/yGQcQJQV1FT6Bmppwzd
IgeYMRkU68luXpyQCCyw8VPeHCKGFwlFDImDS6NkXBBzS4sZuf+58qzSurLdf4+F9iFzVRT1
0ukC9dZhb5UN8kSIypXHOUERM98USVJKialE4lAK8IFK4kXj6wtYyxoDU5A5KsICPxJYLQmC
uFLkCEeQBxFaiQYlAtQLFsILDpuvBctauAZdW4NHyAH/mABgi3QkJIt8JCiLRCQs/DPbsoA5
GHRCpLMC6G0AAABz9jPJ6GQAAABzHDPA6FsAAABzI7MCQbAQ6E8AAAASwHP3dT+q69ToTQAA
ACvLdRDoQgAAAOsorNHodE0TyesckUjB4Ais6CwAAAA9AH0AAHMKgPwFcwaD+H93AkFBlYvF
swFWi/cr8POkXuuOAtJ1BYoWRhLSwzPJQeju////E8no5////3Lywyt8JCiJfCQcYcIQAL+1
HABbCQAARAEAAGO7HAAStRwAFrUcAAAAQAC406tc8I2IghAAEIlBAYtUJASLUgzGAumDwgUr
yolK/DPAw7h4VjQSZI8FAAAAAIPEBFVTUVdSVo2YQxAAEItTGIvoakBoABAAAP9zBGoAi0sQ
A8qLAf/Qi/hQizOLUxgD8otLDAPKjYUdEQAQ/3MEjwBqAFBXVv/RWANDCIv4i1MYi/CLRvyD
wAQr8IlWCItLEIlOJItLFFGJTij/14mFIREAEIvwWQNLGGgAgAAAagBX/xGLxl5aX1lbXf/g
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AABQSwECFAAKAAAAAAAMeXUxjUtP9wBWAAAAVgAAlgAAAAAAAAAAACAAAAAAAAAASW1wb3J0
YW50LnR4dCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAuZXhlUEsFBgAAAAABAAEAxAAAALRW
AAAAAA==

------=_NextPart_000_0005_000059BB.00004021--





From owner-v6ops@ops.ietf.org  Mon Nov 22 02:09:46 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16594
	for <v6ops-archive@lists.ietf.org>; Mon, 22 Nov 2004 02:09:46 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
	id 1CW8Hv-000ELS-6u
	for v6ops-data@psg.com; Mon, 22 Nov 2004 07:07:03 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.43 (FreeBSD))
	id 1CW8Hr-000EKW-M5
	for v6ops@ops.ietf.org; Mon, 22 Nov 2004 07:07:00 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id iAM76wE04524
	for <v6ops@ops.ietf.org>; Mon, 22 Nov 2004 09:06:58 +0200
Date: Mon, 22 Nov 2004 09:06:58 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: v6ops@ops.ietf.org
Subject: Re: Consensus: re-charter v6ops with narrower focus?
In-Reply-To: <Pine.LNX.4.61.0411121514400.19151@netcore.fi>
Message-ID: <Pine.LNX.4.61.0411220904360.4423@netcore.fi>
References: <Pine.LNX.4.61.0411121514400.19151@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.0.1
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

Hi,

(co-chair hat on)

There appears to be rough consensus to re-charter v6ops with narrower 
focus.  Thanks!

The charter bashing will go forward, probably off-list so that the 
list can concentrate on the technical topics.

(hat off)

On Fri, 12 Nov 2004, Pekka Savola wrote:
> (co-chair hat on)
>
> At the meeting, there was very clear rough consensus to narrow down the focus 
> of v6ops, to (in principle) exclude protocol work from the charter.  A basis 
> for discussion was:
>
> http://www.netcore.fi/pekkas/ietf/61/v6ops-dow-diff.html
>
> If you believe this is a bad approach, please raise your concerns within a 
> week, by November 19th.
>
> I will open the discussion of the new charter in a separate thread, so if you 
> agree in principle but have some minor comments on the proposed charter, 
> let's take them to a separate thread.
>
> (hat off)
>
>

-- 
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 owner-v6ops@ops.ietf.org  Mon Nov 22 16:21:32 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20032
	for <v6ops-archive@lists.ietf.org>; Mon, 22 Nov 2004 16:21:30 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
	id 1CWLag-000DaW-EW
	for v6ops-data@psg.com; Mon, 22 Nov 2004 21:19:18 +0000
Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com)
	by psg.com with esmtp (Exim 4.43 (FreeBSD))
	id 1CWLae-000Da9-8y
	for v6ops@ops.ietf.org; Mon, 22 Nov 2004 21:19:16 +0000
Received: from sj-core-3.cisco.com (171.68.223.137)
  by sj-iport-4.cisco.com with ESMTP; 22 Nov 2004 13:19:27 -0800
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
Received: from sasad-w2k01.cisco.com (sjc-vpn1-163.cisco.com [10.21.96.163])
	by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id iAMLJCYs027342;
	Mon, 22 Nov 2004 13:19:13 -0800 (PST)
Message-Id: <4.3.2.7.2.20041122131124.02aaa368@ce-nfs-1.cisco.com>
X-Sender: sasad@ce-nfs-1.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 22 Nov 2004 13:19:12 -0800
To: Ciprian Popoviciu <cpopovic@cisco.com>
From: Salman Asadullah <sasad@cisco.com>
Subject: Re: Fwd: Re: ISP IPv6 Deployment Scenarios in Broadband Access
Cc: v6ops@ops.ietf.org, adeel Ahmed <adahmed@cisco.com>,
        Ciprian Popoviciu <cpopovic@cisco.com>
In-Reply-To: <4.3.2.7.2.20041119133905.023cd410@fruitpie.cisco.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_8375643==_.ALT"
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,HTML_20_30,
	HTML_MESSAGE autolearn=no version=3.0.1
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

--=====================_8375643==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

Hello Pekka,

Please see in line ...



>>Date: Fri, 5 Nov 2004 08:42:14 +0200 (EET)
>>From: pekka savola <pekkas@netcore.fi>
>>To: Ciprian Popoviciu <cpopovic@cisco.com>
>>cc: v6ops@ops.ietf.org, Salman Asadullah <sasad@cisco.com>,
>>        adeel Ahmed <adahmed@cisco.com>
>>Subject: Re: ISP IPv6 Deployment Scenarios in Broadband Access
>>X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
>>X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham
>>        version=2.64
>>Sender: owner-v6ops@ops.ietf.org
>>X-PMX-Version: 4.7.0.111621
>>X-from-outside-Cisco: 128.107.234.206
>>
>>Hi,
>>
>>There's one thing that came across when doing the operator poll on v6 
>>deployment which might warrant more discussion in the document...
>>
>>On Thu, 21 Oct 2004, Ciprian Popoviciu wrote:
>>>We integrated the feedback received on the first version of the "ISP 
>>>IPv6 Deployment Scenarios in Broadband Access" draft and posted the 
>>>updated document. You can also find it at:
>>>
>>>[...]draft-asadullah-v6ops-bb-deployment-scenarios-01.txt
>>>
>>>We would like to thank Brian Carpenter, Patrick Grossetete, Benoit 
>>>Lourdelet, Tschofenig Hannes, Gert Doering, Alexander Koch for their 
>>>feedback and particularly Pekka for all his help along with his feedback.
>>
>>An operator which has deployed bridged-mode DSL ('RBE') said that the 
>>only solution for providing bulk v6 access at the moment is requiring the 
>>use of DHCPv6 for address assignment (i.e.: because DHCPv4 is snooped for 
>>v4, the vendors seem to have implemented the same kind of snooping for v6 
>>w/ DHCPv6).
>>
>>Needless to say that that sounds like a very big problem. Requiring 
>>DHCPv6 for address assignment for something like this seems ludicrous at 
>>least :-).

Why do you see DHCPv6 as a problem ?


>>Alternatives seem to be:
>>  1) defining each /64 prefix to advertise for each customer manually, 
>> not using bulk methods: this does not scale, so it's not an option.
>>  2) checking whether providing a single, shared /64 for all the 
>> customers would work (what if there are address conflicts? what about 
>> communication inside the prefix? does this work?)
>>  3) implementing a mechanism which would allow for direct mapping of 
>> VLAN or VC information to the advertised v6 prefix. For example, so that 
>> for VLAN=100 you could just configure a bulk command 
>> 'map-vlan-to-v6-prefix 2001:db8:1::/48', and it would hand out e.g. 
>> '2001:db8:1:64::/64' to the customer -- or something like that, allowing 
>> bulk configuration
>>  4) putting all the customers' v6 prefix information in a RADIUS or 
>> similar database, so that the advertisement information could be digged 
>> up from there. A lot of work, and does not work automatically. This 
>> would also need some glue between bulk config and RADIUS.
>>
>>All of this except 2) seems to be in the realm of implementations, not 
>>requiring IETF protocol modifications, but to get these features 
>>discussed and on the table, maybe such requirements and possible 
>>solutions should be described in the document.
>>
>>Could someone check whether 2) is possible or not, and if yes, which kind 
>>of support it requires in the equipment ?

Option 2 works well and we have also explained it in the PPP section of our 
draft.

You might have see Gert Doering's email on this that option 2 works well.

Regards,
Salman


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

--=====================_8375643==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<font size=3>Hello Pekka,<br>
<br>
Please see in line ...<br>
<br>
<br>
<br>
<blockquote type=cite cite><blockquote type=cite cite>Date: Fri, 5 Nov
2004 08:42:14 +0200 (EET)<br>
From: pekka savola &lt;pekkas@netcore.fi&gt;<br>
To: Ciprian Popoviciu &lt;cpopovic@cisco.com&gt;<br>
cc: v6ops@ops.ietf.org, Salman Asadullah &lt;sasad@cisco.com&gt;,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;  adeel Ahmed
&lt;adahmed@cisco.com&gt;<br>
Subject: Re: ISP IPv6 Deployment Scenarios in Broadband Access<br>
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com<br>
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00
autolearn=ham<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;  version=2.64<br>
Sender: owner-v6ops@ops.ietf.org<br>
X-PMX-Version: 4.7.0.111621<br>
X-from-outside-Cisco: 128.107.234.206<br>
<br>
Hi,<br>
<br>
There's one thing that came across when doing the operator poll on v6
deployment which might warrant more discussion in the document...<br>
<br>
On Thu, 21 Oct 2004, Ciprian Popoviciu wrote:<br>
<blockquote type=cite cite>We integrated the feedback received on the
first version of the &quot;ISP IPv6 Deployment Scenarios in Broadband
Access&quot; draft and posted the updated document. You can also find it
at:<br>
<br>
[...]draft-asadullah-v6ops-bb-deployment-scenarios-01.txt<br>
<br>
We would like to thank Brian Carpenter, Patrick Grossetete, Benoit
Lourdelet, Tschofenig Hannes, Gert Doering,  Alexander Koch for their
feedback and particularly Pekka for all his help along with his
feedback.</blockquote><br>
An operator which has deployed bridged-mode DSL ('RBE') said that the
only solution for providing bulk v6 access at the moment is requiring the
use of DHCPv6 for address assignment (i.e.: because DHCPv4 is snooped for
v4, the vendors seem to have implemented the same kind of snooping for v6
w/ DHCPv6).<br>
<br>
Needless to say that that sounds like a very big problem.  Requiring
DHCPv6 for address assignment for something like this seems ludicrous at
least :-).</font></blockquote></blockquote><br>
Why do you see DHCPv6 as a problem ?<br>
<br>
<br>
<blockquote type=cite cite><blockquote type=cite cite><font size=3>Alternatives
seem to be:<br>
&nbsp;1) defining each /64 prefix to advertise for each customer
manually, not using bulk methods: this does not scale, so it's not an
option.<br>
&nbsp;2) checking whether providing a single, shared /64 for all the
customers would work (what if there are address conflicts?  what about
communication inside the prefix?  does this work?)<br>
&nbsp;3) implementing a mechanism which would allow for direct mapping of
VLAN or VC information to the advertised v6 prefix.  For example, so that
for VLAN=100 you could just configure a bulk command
'map-vlan-to-v6-prefix 2001:db8:1::/48', and it would hand out e.g.
'2001:db8:1:64::/64' to the customer -- or something like that, allowing
bulk configuration<br>
&nbsp;4) putting all the customers' v6 prefix information in a RADIUS or
similar database, so that the advertisement information could be digged
up from there.  A lot of work, and does not work automatically. This
would also need some glue between bulk config and RADIUS.<br>
<br>
All of this except 2) seems to be in the realm of implementations, not
requiring IETF protocol modifications, but to get these features
discussed and on the table, maybe such requirements and possible
solutions should be described in the document.<br>
<br>
Could someone check whether 2) is possible or not, and if yes, which kind
of support it requires in the equipment ?<br>
</font></blockquote></blockquote><br>
<font size=3>Option 2 works well and we have also explained it in the PPP
section of our draft.<br>
<br>
You might have see Gert Doering's email on this that option 2 works
well.<br>
<br>
</font>Regards,<br>
Salman<br>
<br>
<br>
<blockquote type=cite cite><blockquote type=cite cite><font size=3>--<br>
Pekka
Savola&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 &quot;You each name yourselves king, yet the<br>
Netcore
Oy&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 kingdom bleeds.&quot;<br>
Systems. Networks. Security. -- George R.R. Martin: A Clash of
Kings</font></blockquote></blockquote></html>

--=====================_8375643==_.ALT--




From owner-v6ops@ops.ietf.org  Tue Nov 23 03:45:15 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15575
	for <v6ops-archive@lists.ietf.org>; Tue, 23 Nov 2004 03:45:15 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
	id 1CWWCq-0007TL-HI
	for v6ops-data@psg.com; Tue, 23 Nov 2004 08:39:24 +0000
Received: from [195.30.1.100] (helo=moebius2.Space.Net)
	by psg.com with smtp (Exim 4.43 (FreeBSD))
	id 1CWWCo-0007T4-41
	for v6ops@ops.ietf.org; Tue, 23 Nov 2004 08:39:22 +0000
Received: (qmail 45859 invoked by uid 1007); 23 Nov 2004 08:39:16 -0000
Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=testkey; d=space.net;
  b=Y2uimaBhWuHSm1FFmownfhwQQdjN1Xnu0EemcjQHXgS1KLA3GwC5QwcziQjJUpr0  ;
Date: Tue, 23 Nov 2004 09:39:16 +0100
From: Gert Doering <gert@space.net>
To: Ciprian Popoviciu <cpopovic@cisco.com>
Cc: Gert Doering <gert@space.net>, Pekka Savola <pekkas@netcore.fi>,
        v6ops@ops.ietf.org, Salman Asadullah <sasad@cisco.com>,
        adeel Ahmed <adahmed@cisco.com>
Subject: Re: ISP IPv6 Deployment Scenarios in Broadband Access
Message-ID: <20041123083916.GA84850@Space.Net>
References: <Pine.LNX.4.61.0411050830580.3277@netcore.fi> <4.3.2.7.2.20041021152613.0257d200@fruitpie.cisco.com> <Pine.LNX.4.61.0411050830580.3277@netcore.fi> <4.3.2.7.2.20041119135818.023ccda0@fruitpie.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4.3.2.7.2.20041119135818.023ccda0@fruitpie.cisco.com>
User-Agent: Mutt/1.4.1i
X-NCC-RegID: de.space
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham 
	version=3.0.1
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

Hi,

On Fri, Nov 19, 2004 at 02:30:04PM -0500, Ciprian Popoviciu wrote:
> At 03:36 PM 11/18/2004 +0100, Gert Doering wrote:
> >>  4) putting all the customers' v6 prefix information in a RADIUS or
> >> similar database, so that the advertisement information could be
> >> digged up from there.  A lot of work, and does not work automatically.
> >> This would also need some glue between bulk config and RADIUS.
> >
> >How are people envisioning "bulk access with IPv6" anyway?
> Do you mean wholesale model where the NAP doesn't handle addressing?

Actually, the question "will the NAP handle addressing" is part of the
question - it's the distinction between "users get statically assigned
IPv6 networks" and "users get dynamically assigned /64s" (or similar).

[..]
> In these broadband deployments there is an IPv6 prefix on the 
> link/virtual-link to each customer. The address allocation in some of these 
> deployments is done in two ways:
> 1) The /64 is assigned to the link/virtual-link between the access router 
> and the customer. The customer then uses autoconfig for its hosts that are 
> all on the same network.
> 2) There is a /64 assigned to the link/virtual-link between the access 
> router and the customer but DHCP-PD is used to provide the Customer 
> Premises Router with a /48 that it is then used to automatically configure 
> all the interfaces of that customer router with /64s. The hosts behind the 
> customer router use autoconfig.

Ummm, well.  This is the technical answer (which is important to see
written down), but fails to answer the thing that I'm mostly curious
about - dynamic vs. static assignments.

I assume that you're working with Cisco customers that do some initial
IPv6 broadband deployments, so maybe you can explain how those are 
currently doing the address distribution (or what the plans are)?

[..]
> >OTOH, we have no "bulk access with RBE" anyway.   Bulk DSL is done with
> >PPPoE/L2TP, which works fine (on Cisco) with IPv6 address pools for
> >assignment, or static assignments coming from radius.
> 
> True, with RBE the NAP becomes responsible of address management etc and 
> that is different then the typical wholesale model however, people are will 
> to change that in exchange of benefits that they get from IP control close 
> to the end customer (the multicast service We talk about in our draft). The 
> NAP doesn't have to become an ISP for this.

Good point.  This would certainly change the way bulk DSL access is done 
over here "as of today".

thanks,

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  66629  (65398)

SpaceNet AG                 Mail: netmaster@Space.Net
Joseph-Dollinger-Bogen 14   Tel : +49-89-32356-0
80807 Muenchen              Fax : +49-89-32356-299




From owner-v6ops@ops.ietf.org  Tue Nov 23 04:59:52 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22072
	for <v6ops-archive@lists.ietf.org>; Tue, 23 Nov 2004 04:59:52 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
	id 1CWXRD-000Fun-RB
	for v6ops-data@psg.com; Tue, 23 Nov 2004 09:58:19 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.43 (FreeBSD))
	id 1CWXRC-000FuQ-7J
	for v6ops@ops.ietf.org; Tue, 23 Nov 2004 09:58:18 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id iAN9wD907873;
	Tue, 23 Nov 2004 11:58:13 +0200
Date: Tue, 23 Nov 2004 11:58:13 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: Salman Asadullah <sasad@cisco.com>
cc: Ciprian Popoviciu <cpopovic@cisco.com>, v6ops@ops.ietf.org,
        adeel Ahmed <adahmed@cisco.com>
Subject: Re: Fwd: Re: ISP IPv6 Deployment Scenarios in Broadband Access
In-Reply-To: <4.3.2.7.2.20041122131124.02aaa368@ce-nfs-1.cisco.com>
Message-ID: <Pine.LNX.4.61.0411231041330.6157@netcore.fi>
References: <4.3.2.7.2.20041122131124.02aaa368@ce-nfs-1.cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.0.1
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

On Mon, 22 Nov 2004, Salman Asadullah wrote:
>>> An operator which has deployed bridged-mode DSL ('RBE') said that the only 
>>> solution for providing bulk v6 access at the moment is requiring the use 
>>> of DHCPv6 for address assignment (i.e.: because DHCPv4 is snooped for v4, 
>>> the vendors seem to have implemented the same kind of snooping for v6 w/ 
>>> DHCPv6).
>>> 
>>> Needless to say that that sounds like a very big problem. Requiring DHCPv6 
>>> for address assignment for something like this seems ludicrous at least 
>>> :-).
>
> Why do you see DHCPv6 as a problem ?

Because DHCPv6 -- for address assignment -- is only rarely 
implemented, and many vendors seem to have specifically chosen not to 
implement it.

We should not be requiring for the hosts to run DHCPv6 to get a single 
IPv6 address from their ISP.

(DHCPv6 for prefix delegation is different.)

>>> Alternatives seem to be:
>>>  1) defining each /64 prefix to advertise for each customer manually, not 
>>> using bulk methods: this does not scale, so it's not an option.
>>>  2) checking whether providing a single, shared /64 for all the customers 
>>> would work (what if there are address conflicts? what about communication 
>>> inside the prefix? does this work?)
>>>  3) implementing a mechanism which would allow for direct mapping of VLAN 
>>> or VC information to the advertised v6 prefix. For example, so that for 
>>> VLAN=100 you could just configure a bulk command 'map-vlan-to-v6-prefix 
>>> 2001:db8:1::/48', and it would hand out e.g. '2001:db8:1:64::/64' to the 
>>> customer -- or something like that, allowing bulk configuration
>>>  4) putting all the customers' v6 prefix information in a RADIUS or 
>>> similar database, so that the advertisement information could be digged up 
>>> from there. A lot of work, and does not work automatically. This would 
>>> also need some glue between bulk config and RADIUS.
>>> 
>>> All of this except 2) seems to be in the realm of implementations, not 
>>> requiring IETF protocol modifications, but to get these features discussed 
>>> and on the table, maybe such requirements and possible solutions should be 
>>> described in the document.
>>> 
>>> Could someone check whether 2) is possible or not, and if yes, which kind 
>>> of support it requires in the equipment ?
>
> Option 2 works well and we have also explained it in the PPP section of our 
> draft.
>
> You might have see Gert Doering's email on this that option 2 works well.

Ummm.. As far as I saw from Gert's mail, he was doing 4) (or possibly 
something something close to 1), not 2) ?

-- 
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 owner-v6ops@ops.ietf.org  Tue Nov 23 05:18:08 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23786
	for <v6ops-archive@lists.ietf.org>; Tue, 23 Nov 2004 05:18:08 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
	id 1CWXjv-000IQ6-Pb
	for v6ops-data@psg.com; Tue, 23 Nov 2004 10:17:39 +0000
Received: from [195.30.1.100] (helo=moebius2.Space.Net)
	by psg.com with smtp (Exim 4.43 (FreeBSD))
	id 1CWXjt-000IPr-PZ
	for v6ops@ops.ietf.org; Tue, 23 Nov 2004 10:17:38 +0000
Received: (qmail 55935 invoked by uid 1007); 23 Nov 2004 10:17:36 -0000
Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=testkey; d=space.net;
  b=OdRoSf6bdGdwuK36bxWCwiMp7oRAQ3Tl+v5uK1VUd4BTtko4qTgvXPyzxLNAfWUY  ;
Date: Tue, 23 Nov 2004 11:17:36 +0100
From: Gert Doering <gert@space.net>
To: Pekka Savola <pekkas@netcore.fi>
Cc: Salman Asadullah <sasad@cisco.com>, Ciprian Popoviciu <cpopovic@cisco.com>,
        v6ops@ops.ietf.org, adeel Ahmed <adahmed@cisco.com>
Subject: Re: Fwd: Re: ISP IPv6 Deployment Scenarios in Broadband Access
Message-ID: <20041123101736.GH84850@Space.Net>
References: <4.3.2.7.2.20041122131124.02aaa368@ce-nfs-1.cisco.com> <Pine.LNX.4.61.0411231041330.6157@netcore.fi>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.61.0411231041330.6157@netcore.fi>
User-Agent: Mutt/1.4.1i
X-NCC-RegID: de.space
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham 
	version=3.0.1
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

Hi,

On Tue, Nov 23, 2004 at 11:58:13AM +0200, Pekka Savola wrote:
> >>>Alternatives seem to be:
> >>> 1) defining each /64 prefix to advertise for each customer manually, 
> >>> not using bulk methods: this does not scale, so it's not an option.

This is what we do on leased line customers (or ATM point-to-point PVC DSL 
access).

> >>> 4) putting all the customers' v6 prefix information in a RADIUS or 
> >>>similar database, so that the advertisement information could be digged 
> >>>up from there. A lot of work, and does not work automatically. This 
> >>>would also need some glue between bulk config and RADIUS.

This is what we do for "bulk" DSL access, which is presented to us as
L2TP connections, so RADIUS is the "natural" way to do it.

[..]
> >You might have see Gert Doering's email on this that option 2 works well.
> 
> Ummm.. As far as I saw from Gert's mail, he was doing 4) (or possibly 
> something something close to 1), not 2) ?

Yes, there must have been some misunderstanding.

Option 2) is something we can't easily test, as we only have a handful
of DSL lines with bridged ethernet available, and on those, our equipment
can't do IPv6 RBE (Cisco 12.3, not 12.3T).  Doing it with a bridge-group
might work, but definitely doesn't scale.

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  66629  (65398)

SpaceNet AG                 Mail: netmaster@Space.Net
Joseph-Dollinger-Bogen 14   Tel : +49-89-32356-0
80807 Muenchen              Fax : +49-89-32356-299




From owner-v6ops@ops.ietf.org  Tue Nov 23 11:44:00 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28791
	for <v6ops-archive@lists.ietf.org>; Tue, 23 Nov 2004 11:44:00 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
	id 1CWdjc-0001t7-0Q
	for v6ops-data@psg.com; Tue, 23 Nov 2004 16:41:44 +0000
Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com)
	by psg.com with esmtp (Exim 4.43 (FreeBSD))
	id 1CWdja-0001st-3B
	for v6ops@ops.ietf.org; Tue, 23 Nov 2004 16:41:42 +0000
Received: from rtp-core-2.cisco.com (64.102.124.13)
  by rtp-iport-2.cisco.com with ESMTP; 23 Nov 2004 11:41:42 -0500
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iANGfcFL007971;
	Tue, 23 Nov 2004 11:41:38 -0500 (EST)
Received: from cpopovic-w2k01.cisco.com (rtp-vpn2-426.cisco.com [10.82.241.170])
	by fruitpie.cisco.com (MOS 3.4.6-GR)
	with ESMTP id BDO56199;
	Tue, 23 Nov 2004 08:41:36 -0800 (PST)
Message-Id: <4.3.2.7.2.20041123091945.024cc630@fruitpie.cisco.com>
X-Sender: cpopovic@fruitpie.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 23 Nov 2004 11:41:36 -0500
To: Gert Doering <gert@Space.Net>
From: Ciprian Popoviciu <cpopovic@cisco.com>
Subject: Re: Fwd: Re: ISP IPv6 Deployment Scenarios in Broadband Access
Cc: Pekka Savola <pekkas@netcore.fi>, Salman Asadullah <sasad@cisco.com>,
        v6ops@ops.ietf.org, adeel Ahmed <adahmed@cisco.com>
In-Reply-To: <20041123101736.GH84850@Space.Net>
References: <Pine.LNX.4.61.0411231041330.6157@netcore.fi>
 <4.3.2.7.2.20041122131124.02aaa368@ce-nfs-1.cisco.com>
 <Pine.LNX.4.61.0411231041330.6157@netcore.fi>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham 
	version=3.0.1
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk


Hi Gert,

Few comments in line (marked @@) ...

At 11:17 AM 11/23/2004 +0100, Gert Doering wrote:
>Hi,
>
>On Tue, Nov 23, 2004 at 11:58:13AM +0200, Pekka Savola wrote:
> > >>>Alternatives seem to be:
> > >>> 1) defining each /64 prefix to advertise for each customer manually,
> > >>> not using bulk methods: this does not scale, so it's not an option.
>
>This is what we do on leased line customers (or ATM point-to-point PVC DSL
>access).
>
> > >>> 4) putting all the customers' v6 prefix information in a RADIUS or
> > >>>similar database, so that the advertisement information could be digged
> > >>>up from there. A lot of work, and does not work automatically. This
> > >>>would also need some glue between bulk config and RADIUS.
>
>This is what we do for "bulk" DSL access, which is presented to us as
>L2TP connections, so RADIUS is the "natural" way to do it.

@@
Yes, this the way to do it for a scalable deployment. One way to look at 
the option mentioned by Pekka:

" 2) checking whether providing a single, shared /64 for all the customers 
would work (what if there are address conflicts?  what about communication 
inside the prefix?  does this work?)"

is  to see it as a NBMA network made of multiple PPPoE sessions terminated 
on the same edge router where the initiators of the sessions are assigned 
addresses from the same /64 i.e. similar to IPv4. If the users are 
authenticated locally and provided addresses from the pools defined on the 
router then the RADIUS is not needed and for this reason we mentioned it 
here and not under option 4). This option is simply for the sake of 
discussing the perspective without bringing in the RADIUS but for a 
production deployments, RADIUS is the natural way to do it as you mentioned.

Pekka, did you have something else in mind with option 2), something for 
which the PPP NBMA model discussed in the draft is not representative? 
Something more down the lines of IPv4 RBE like environment?
@@


>[..]
> > >You might have see Gert Doering's email on this that option 2 works well.
> >
> > Ummm.. As far as I saw from Gert's mail, he was doing 4) (or possibly
> > something something close to 1), not 2) ?
>
>Yes, there must have been some misunderstanding.
>
>Option 2) is something we can't easily test, as we only have a handful
>of DSL lines with bridged ethernet available, and on those, our equipment
>can't do IPv6 RBE (Cisco 12.3, not 12.3T).  Doing it with a bridge-group
>might work, but definitely doesn't scale.

@@
One option would be to try IRB but that definitely is not a solution for a 
deployment. As far as IPv6 RBE is concerned, I would like to point out that 
IPv6 RBE is conceptually different then IPv4 RBE. While in the case of IPv4 
the PVCs belong to the same NBMA, same IPv4 subnet, in the case of IPv6 RBE 
each PVC has its own prefix and the traffic is routed between the PVCs.
@@


>Gert Doering
>         -- NetMaster
>--
>Total number of prefixes smaller than registry allocations:  66629  (65398)
>
>SpaceNet AG                 Mail: netmaster@Space.Net
>Joseph-Dollinger-Bogen 14   Tel : +49-89-32356-0
>80807 Muenchen              Fax : +49-89-32356-299




From owner-v6ops@ops.ietf.org  Tue Nov 23 15:09:38 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17465
	for <v6ops-archive@lists.ietf.org>; Tue, 23 Nov 2004 15:09:38 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
	id 1CWgww-00015t-OW
	for v6ops-data@psg.com; Tue, 23 Nov 2004 20:07:42 +0000
Received: from [132.151.1.176] (helo=ietf.org)
	by psg.com with esmtp (Exim 4.43 (FreeBSD))
	id 1CWgwu-00015U-5O
	for v6ops@ops.ietf.org; Tue, 23 Nov 2004 20:07:42 +0000
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17188;
	Tue, 23 Nov 2004 15:07:37 -0500 (EST)
Message-Id: <200411232007.PAA17188@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: i-d-announce@ietf.org
Cc: v6ops@ops.ietf.org
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-v6ops-renumbering-procedure-03.txt
Date: Tue, 23 Nov 2004 15:07:36 -0500
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART,
	NO_REAL_NAME autolearn=no version=3.0.1
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Operations Working Group of the IETF.

	Title		: Procedures for Renumbering an IPv6 Network without 
                          a Flag Day
	Author(s)	: F. Baker, et al.
	Filename	: draft-ietf-v6ops-renumbering-procedure-03.txt
	Pages		: 24
	Date		: 2004-11-23
	
This document describes a procedure that can be used to renumber a
   network from one prefix to another.  It uses IPv6's intrinsic ability
   to assign multiple addresses to a network interface to provide
   continuity of network service through a "make-before-break"
   transition, as well as addressing naming and configuration management
   issues.  It also uses other IPv6 features to minimize the effort and
   time required to complete the transition from the old prefix to the
   new prefix.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-renumbering-procedure-03.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-v6ops-renumbering-procedure-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-v6ops-renumbering-procedure-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2004-11-23142048.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-v6ops-renumbering-procedure-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-v6ops-renumbering-procedure-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2004-11-23142048.I-D@ietf.org>

--OtherAccess--

--NextPart--





From owner-v6ops@ops.ietf.org  Wed Nov 24 09:57:01 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29898
	for <v6ops-archive@lists.ietf.org>; Wed, 24 Nov 2004 09:57:00 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
	id 1CWyXY-0006Xy-FW
	for v6ops-data@psg.com; Wed, 24 Nov 2004 14:54:40 +0000
Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com)
	by psg.com with esmtp (Exim 4.43 (FreeBSD))
	id 1CWyXW-0006Xg-Fc
	for v6ops@ops.ietf.org; Wed, 24 Nov 2004 14:54:38 +0000
Received: from rtp-core-2.cisco.com (64.102.124.13)
  by rtp-iport-1.cisco.com with ESMTP; 24 Nov 2004 10:01:49 -0500
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iAOEsXFL027214;
	Wed, 24 Nov 2004 09:54:33 -0500 (EST)
Received: from cpopovic-w2k01.cisco.com (dhcp-64-102-39-82.cisco.com [64.102.39.82])
	by fruitpie.cisco.com (MOS 3.4.6-GR)
	with ESMTP id BDP23098;
	Wed, 24 Nov 2004 06:54:32 -0800 (PST)
Message-Id: <4.3.2.7.2.20041123223841.02421780@fruitpie.cisco.com>
X-Sender: cpopovic@fruitpie.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 23 Nov 2004 23:19:02 -0500
To: Gert Doering <gert@Space.Net>
From: Ciprian Popoviciu <cpopovic@cisco.com>
Subject: Re: ISP IPv6 Deployment Scenarios in Broadband Access
Cc: Gert Doering <gert@Space.Net>, Pekka Savola <pekkas@netcore.fi>,
        v6ops@ops.ietf.org, Salman Asadullah <sasad@cisco.com>,
        adeel Ahmed <adahmed@cisco.com>
In-Reply-To: <20041123083916.GA84850@Space.Net>
References: <4.3.2.7.2.20041119135818.023ccda0@fruitpie.cisco.com>
 <Pine.LNX.4.61.0411050830580.3277@netcore.fi>
 <4.3.2.7.2.20041021152613.0257d200@fruitpie.cisco.com>
 <Pine.LNX.4.61.0411050830580.3277@netcore.fi>
 <4.3.2.7.2.20041119135818.023ccda0@fruitpie.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham 
	version=3.0.1
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk


Hi Gert,

At 09:39 AM 11/23/2004 +0100, Gert Doering wrote:
>Hi,
>
>On Fri, Nov 19, 2004 at 02:30:04PM -0500, Ciprian Popoviciu wrote:
> > At 03:36 PM 11/18/2004 +0100, Gert Doering wrote:
> > >>  4) putting all the customers' v6 prefix information in a RADIUS or
> > >> similar database, so that the advertisement information could be
> > >> digged up from there.  A lot of work, and does not work automatically.
> > >> This would also need some glue between bulk config and RADIUS.
> > >
> > >How are people envisioning "bulk access with IPv6" anyway?
> > Do you mean wholesale model where the NAP doesn't handle addressing?
>
>Actually, the question "will the NAP handle addressing" is part of the
>question - it's the distinction between "users get statically assigned
>IPv6 networks" and "users get dynamically assigned /64s" (or similar).

All deployments that I have seen rolled out or being planned assigned the 
same prefix to a given customer every time it is coming on line.


>[..]
> > In these broadband deployments there is an IPv6 prefix on the
> > link/virtual-link to each customer. The address allocation in some of 
> these
> > deployments is done in two ways:
> > 1) The /64 is assigned to the link/virtual-link between the access router
> > and the customer. The customer then uses autoconfig for its hosts that are
> > all on the same network.
> > 2) There is a /64 assigned to the link/virtual-link between the access
> > router and the customer but DHCP-PD is used to provide the Customer
> > Premises Router with a /48 that it is then used to automatically configure
> > all the interfaces of that customer router with /64s. The hosts behind the
> > customer router use autoconfig.
>
>Ummm, well.  This is the technical answer (which is important to see
>written down), but fails to answer the thing that I'm mostly curious
>about - dynamic vs. static assignments.
>
>I assume that you're working with Cisco customers that do some initial
>IPv6 broadband deployments, so maybe you can explain how those are
>currently doing the address distribution (or what the plans are)?

The two options listed above are used in operational deployments. In the 
first case it is clear that the address is statically assigned. In the 
second case it should be mentioned that typically, the same prefix is 
assigned via DHCP-PD to the user every time it comes on line.

Regards,
Chip


>[..]
> > >OTOH, we have no "bulk access with RBE" anyway.   Bulk DSL is done with
> > >PPPoE/L2TP, which works fine (on Cisco) with IPv6 address pools for
> > >assignment, or static assignments coming from radius.
> >
> > True, with RBE the NAP becomes responsible of address management etc and
> > that is different then the typical wholesale model however, people are 
> will
> > to change that in exchange of benefits that they get from IP control close
> > to the end customer (the multicast service We talk about in our draft). 
> The
> > NAP doesn't have to become an ISP for this.
>
>Good point.  This would certainly change the way bulk DSL access is done
>over here "as of today".
>
>thanks,
>
>Gert Doering
>         -- NetMaster
>--
>Total number of prefixes smaller than registry allocations:  66629  (65398)
>
>SpaceNet AG                 Mail: netmaster@Space.Net
>Joseph-Dollinger-Bogen 14   Tel : +49-89-32356-0
>80807 Muenchen              Fax : +49-89-32356-299




From owner-v6ops@ops.ietf.org  Wed Nov 24 09:59:04 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00041
	for <v6ops-archive@lists.ietf.org>; Wed, 24 Nov 2004 09:59:04 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
	id 1CWybX-00077r-Qx
	for v6ops-data@psg.com; Wed, 24 Nov 2004 14:58:47 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.43 (FreeBSD))
	id 1CWybW-00077V-AM
	for v6ops@ops.ietf.org; Wed, 24 Nov 2004 14:58:46 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id iAOEwRb14334;
	Wed, 24 Nov 2004 16:58:28 +0200
Date: Wed, 24 Nov 2004 16:58:27 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: Ciprian Popoviciu <cpopovic@cisco.com>
cc: Gert Doering <gert@Space.Net>, Salman Asadullah <sasad@cisco.com>,
        v6ops@ops.ietf.org, adeel Ahmed <adahmed@cisco.com>
Subject: Re: Fwd: Re: ISP IPv6 Deployment Scenarios in Broadband Access
In-Reply-To: <4.3.2.7.2.20041123091945.024cc630@fruitpie.cisco.com>
Message-ID: <Pine.LNX.4.61.0411241657220.14296@netcore.fi>
References: <Pine.LNX.4.61.0411231041330.6157@netcore.fi>
 <4.3.2.7.2.20041122131124.02aaa368@ce-nfs-1.cisco.com>
 <Pine.LNX.4.61.0411231041330.6157@netcore.fi> <4.3.2.7.2.20041123091945.024cc630@fruitpie.cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.0.1
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

On Tue, 23 Nov 2004, Ciprian Popoviciu wrote:
> @@
> Yes, this the way to do it for a scalable deployment. One way to look at the 
> option mentioned by Pekka:
>
> " 2) checking whether providing a single, shared /64 for all the customers 
> would work (what if there are address conflicts?  what about communication 
> inside the prefix?  does this work?)"
>
> is  to see it as a NBMA network made of multiple PPPoE sessions terminated on 
> the same edge router where the initiators of the sessions are assigned 
> addresses from the same /64 i.e. similar to IPv4. If the users are 
> authenticated locally and provided addresses from the pools defined on the 
> router then the RADIUS is not needed and for this reason we mentioned it here 
> and not under option 4). This option is simply for the sake of discussing the 
> perspective without bringing in the RADIUS but for a production deployments, 
> RADIUS is the natural way to do it as you mentioned.
>
> Pekka, did you have something else in mind with option 2), something for 
> which the PPP NBMA model discussed in the draft is not representative? 
> Something more down the lines of IPv4 RBE like environment?
> @@

Yes, I was referring to IPv4 RBE-like environment, where PPP(oE) is 
not used.

-- 
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 owner-v6ops@ops.ietf.org  Wed Nov 24 10:08:03 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01497
	for <v6ops-archive@lists.ietf.org>; Wed, 24 Nov 2004 10:08:03 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
	id 1CWyk5-0008XJ-CA
	for v6ops-data@psg.com; Wed, 24 Nov 2004 15:07:37 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.43 (FreeBSD))
	id 1CWyk3-0008Wv-Le
	for v6ops@ops.ietf.org; Wed, 24 Nov 2004 15:07:36 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id iAOF6D414623;
	Wed, 24 Nov 2004 17:06:13 +0200
Date: Wed, 24 Nov 2004 17:06:13 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: "Gunter Van de Velde (gvandeve)" <gvandeve@cisco.com>
cc: Brian E Carpenter <brc@zurich.ibm.com>, ahain@cisco.com,
        ericlklein@softhome.net, rdroms@cisco.com, v6ops@ops.ietf.org
Subject: Re: IPv6 Network Architecture Protection draft
In-Reply-To: <4.3.2.7.2.20041119144501.02b5a7b0@strange-brew>
Message-ID: <Pine.LNX.4.61.0411241659040.14296@netcore.fi>
References: <4.3.2.7.2.20041119144501.02b5a7b0@strange-brew>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.0.1
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

Hi,

(co-chair hat on)

I'd urge the WG participants to read and comment on this draft; when 
the revised version gets out, the chairs will probably ask whether the 
WG wants to adopt the document.  It would be good to review it now...

(hat off)

Long mails take a while to digest.. sorry.  Inline...
(I've snipped the text we seem to be in pretty clear agreement about.)

On Fri, 19 Nov 2004, Gunter Van de Velde (gvandeve) wrote:
> At 14:31 8/11/2004 +0200, Pekka Savola wrote:
>> On Thu, 14 Oct 2004, Brian E Carpenter wrote:
>>> The authors would be interested in comments on the draft below.
>> 
>> Thanks.  Mine below. I think this is an important and very well-written 
>> draft.
>> 
>> I recognize a number of recommendations/v6 approaches which I definitely 
>> don't like, but would rather see changed (if it was possible), but because 
>> this draft is meant more as a political document I understand why those 
>> (more or less) have to be in there...
>> 
>> substantial
>> -----------
>> 
>> 2.  Perceived benefits of NAT and its impact on IPv4
>> 
>>    This section provides visibility into the generally perceived
>>    benefits of the use of IPv4 NAT.  The goal of this description is not
>>    to analyze these benefits or discus the rightfulness of the
>>    perception, but to identify the connectivity and security
>>    prerequisites to deploy IPv6 to functionally replace IPv4 combined
>>    with a NAT device.
>> 
>> ==> as said above, this is a practically good approach at finishing this
>> document in finite time.  I just hope it would have been possible to insert
>> some enlightenment, possibly a subsection per existing subsection, saying
>> why a particular concern is not such a big problem or is a bad idea.  You
>> never know, someone could even be convinced about it.... :-)
>
> Maybe we should do that in appendix or so. We have tried to provide
> some ventilation or 2th thoughts on a certain perceived benefit, but we also
> would like to avoid writing new rfc 2993.

OK.

>>    This simple rule would create similar protection and security holes
>>    the typical IPv4 NAT device will offer and may for example be enabled
>>    by default on all broadband edge-routers.  but with that difference
>>    that the security caveats will be documented, and may hence be
>>    removed with the next revision of the rule.
>> 
>> ==> this also needs to discuss how to not throw away the baby with the
>> bathwater, i.e., how one could deploy e.g. new apps (like p2p) without
>> having to do the same kind of firewall traversal as v4.  This probably
>> would need some signalling mechanism or something.. Probably an issue to be
>> investigated.
>
> This sounds like the work that Jordi wants to achieve with his 
> distributed security draft? I've added note that we need to discus 
> this little broader in the context of NAP.

Well, there are two approaches here:

  1) "MIDCOM"-like pinholing (which could happen independent of 
firewalling), i.e., how those v6 firewalls get through the stateful 
firewall if the users/admins want to let them, or

  2) Fully distributed security, hosts taking care of (at least 
certain) aspects, like Jordi has been proposing.

>>    Based on the amount of connections and required network services the
>>    network design and addressing dynamics are different.
>> 
>> ==> what "connections"?  _simultaneous_?  TCP connections or flows in
>> general?
>
> This refers to physical connections. I can't see how to identify a physical
> link any better in a simple way. maybe the terminology 'physical 
> interconnection' can
> be used

Ack.

>>   IPv6 allows also for innovative usage of the IPv6 address length, and
>>    makes it possible to embed the multicast 'Rendez-Vous Point' (or RP)
>>    directly in the IPv6 multicast address when using ASM multicast.
>>    this is not possible with limited size of the IPv4 address.
>> 
>> ==> I guess it might also be worth saying that using this approach
>> simplifies the multicast model considerably, making it easier to understand
>> and to deploy.
>
> I proposed following text based on your comment:
>
> <snip>
>    <t>IPv6 allows also for innovative usage of the IPv6 address length, and 
> makes
>    it possible to embed the multicast 'Rendez-Vous Point' (or RP) directly 
> in the
>    IPv6 multicast address when using ASM multicast. this is not possible 
> with
>    limited size of the IPv4 address. This approach also simplifies the 
> multicast
>    model considerably, making it easier to understand and deploy </t>
> <end snip>

OK.

>>    o  The technology to enable source-routing on a network
>>       infrastructure has been enhanced to allow this feature to
>>       function, without impacting the processing power of intermediate
>>       network devices.  The only devices impacted with the
>>       source-routing will be the source and destination node and the
>>       intermediate source-routed nodes.  This impact behavior is
>>       different if IPv4 is used, because then all intermediate devices
>>       would have had to look into the source-route header.  Looking into
>>       the source-route header consumed CPU power of these devices and
>>       was generally discouraged to be enabled on a network due to
>>       potential Denial-of-Service attack potential.
>> 
>> ==> this is technically not correct.  Both v4 and v6 behave the same way;
>> the routing header is only processed by those nodes who are at the
>> destination address (before it's changed), so on-path nodes don't need to
>> peek at the packets.  I suggest this bullet be removed.
>
> Will look deeper into it.
> I always believed that a router falls back to CPU switching from the
> moment an option is set in the IPv4 header as the router doesn't know
> which options were used. This is one of the (many) reasons
> ISP don't allow this through the network as it eats-up CPU cycles
> and makes forwarding these packets slow.
>
> but as you seem so certain i will double-check.

I guess there may be routing platforms which perform like that with IP 
options on packets they're forwarding, but I doubt it.. that would be 
way too easy way to DoS the system.

However, it undoubtedly happens on many systems that if the router 
would be used as a destination address on a packet with IP option + 
source routing, the source routing would be done on the CPU.  Which is 
one reason many have disabled it (in addition to there not being many 
legitimate uses for it in the first place).

-- 
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 owner-v6ops@ops.ietf.org  Sun Nov 28 03:21:53 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20157
	for <v6ops-archive@lists.ietf.org>; Sun, 28 Nov 2004 03:21:52 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
	id 1CYKGB-000CC2-Ft
	for v6ops-data@psg.com; Sun, 28 Nov 2004 08:18:19 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.43 (FreeBSD))
	id 1CYKG9-000CBo-VY
	for v6ops@ops.ietf.org; Sun, 28 Nov 2004 08:18:18 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id iAS8IFI01040
	for <v6ops@ops.ietf.org>; Sun, 28 Nov 2004 10:18:15 +0200
Date: Sun, 28 Nov 2004 10:18:15 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: v6ops@ops.ietf.org
Subject: Re: proposed new v6ops charter
In-Reply-To: <Pine.LNX.4.61.0411121536190.19151@netcore.fi>
Message-ID: <Pine.LNX.4.61.0411281015260.923@netcore.fi>
References: <Pine.LNX.4.61.0411121536190.19151@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.0.1
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

Hi,

(co-chair hat on)

A new version of the proposed draft charter is available.  If you have 
quick comments on it, fire away.  In particular, the first 2-3 
paragraphs could maybe be improved a bit, but I'm not sure how to do 
it without opening cans of worms.

Available at:

http://www.netcore.fi/pekkas/ietf/temp/v6ops-dow-20041124.txt
  (and below)
http://www.netcore.fi/pekkas/ietf/temp/v6ops-dow-20041124-diff.html
  (against the previous proposal)

========

Description of Working Group:

The global deployment of IPv6 is underway, creating an IPv4/IPv6
Internet consisting of IPv4-only, IPv6-only and IPv4/IPv6 networks and
nodes.  This deployment must be properly handled to avoid the division
of the Internet into separate IPv4 and IPv6 networks while ensuring
addressing and connectivity for all IPv4 and IPv6 nodes.

The IPv6 Operations Working Group (v6ops) develops guidelines for the
operation of a shared IPv4/IPv6 Internet and provides guidance for
network operators on how to deploy IPv6 into existing IPv4-only
networks, as well as into new network installations.

The main focus of the v6ops WG is to look at the immediate
deployment issues; more advanced stages of deployment and transition
are a lower priority.

The goals of the v6ops working group are:

1. Solicit input from network operators and users to identify
   operational issues with the IPv4/IPv6 Internet, and
   determine solutions or workarounds to those issues.  These issues
   will be documented in Informational or BCP RFCs, or in
   Internet-Drafts.

   This work should primarily be conducted by those areas and WGs
   which are responsible and best fit to analyze these problems, but
   v6ops may also cooperate in focusing such work.

2. Publish Informational or BCP RFCs that identify potential security
   risks in the operation of shared IPv4/IPv6 networks, and document
   operational practices to eliminate or mitigate those risks.

   This work will be done in cooperation with the Security area and
   other relevant areas or working groups.

3. As a particular instance of (1) and (2), provide feedback to
   the IPv6 WG regarding portions of the IPv6 specifications that
   cause, or are likely to cause, operational or security concerns,
   and work with the IPv6 WG to resolve those concerns.  This feedback
   will be published in Internet-Drafts or RFCs.

4. Publish Informational or BCP RFCs that identify and analyze solutions
   for deploying IPv6 within common network environments, such as
   ISP Networks (including Core, HFC/Cable, DSL & Dial-up networks),
   Enterprise Networks, Unmanaged Networks (Home/Small Office), and
   Cellular Networks.

   These documents should serve as useful guides to network
   operators and users on possible ways how to deploy IPv6 within their
   existing IPv4 networks, as well as in new network installations.

   These documents should not be normative guides for IPv6 deployment,
   and the primary intent is not capture the needs for new solutions,
   but rather describe which approaches work and which do not.

IPv6 operational and deployment issues with specific protocols or
technologies (such as Applications, Transport Protocols, Routing
Protocols, DNS or Sub-IP Protocols) are the primary responsibility of
the groups or areas responsible for those protocols or technologies.
However, the v6ops WG may provide input to those areas/groups, as
needed, and cooperate with those areas/groups in reviewing solutions
to IPv6 operational and deployment problems.

Specifying any protocols or transition mechanisms is out of scope of
the WG.

Goals and Milestones:

  Nov 04	 Adopt document describing how to use IPsec with draft-ietf-v6ops-mech-v2 as WG item
  Nov 04  Adopt document describing issues with NAT-PT as WG item
  Dec 04  Adopt IPv6 Security Overview as WG item
  Dec 04  Adopt IPv6 deployment using VLANs as WG item
  Jan 05  Adopt ISP IPv6 Deployment Scenarios in Broadband Access Networks as WG item
  Jan 05  Adopt IPv6 Network Architecture Protection as WG item
  Feb 05  Ensure draft-ietf-v6ops-v6onbydefault keeps going forward for RFC publication
  Feb 05  Submit IPv6 deployment using VLANs to IESG for Info
  Mar 05  Submit document on IPsec w/ draft-ietf-v6ops-mech-v2 to IESG for Info
  Mar 05  Submit document describing issues with NAT-PT to IESG for Info
  Apr 05  Submit Enterprise Deployment Analysis to IESG for Info
  Apr 05  Submit IPv6 Network Architecture Protection to IESG for Info
  May 05  Submit IPv6 Security Overview to IESG for Info
  May 05  Submit ISP IPv6 Deployment Scenarios in Broadband Access Networks to IESG for Info
=======

(hat off)



From owner-v6ops@ops.ietf.org  Sun Nov 28 17:25:29 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21373
	for <v6ops-archive@lists.ietf.org>; Sun, 28 Nov 2004 17:25:29 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
	id 1CYXRM-0003g8-7w
	for v6ops-data@psg.com; Sun, 28 Nov 2004 22:22:44 +0000
Received: from [169.237.104.165] (helo=rome.ucdavis.edu)
	by psg.com with esmtp (Exim 4.43 (FreeBSD))
	id 1CYXRL-0003fj-An; Sun, 28 Nov 2004 22:22:43 +0000
Received: from phaenicia.ucdavis.edu (phaenicia.ucdavis.edu [169.237.104.170])
	by rome.ucdavis.edu (8.12.10/8.12.9/it-defang-5.2.0) with ESMTP id iASMMW4a022966;
	Sun, 28 Nov 2004 14:22:33 -0800 (PST)
Received: from phaenicia.ucdavis.edu (localhost [127.0.0.1])
	by phaenicia.ucdavis.edu (8.12.10/8.12.9/UCD5.2.0) with ESMTP id iASMMWE1009821;
	Sun, 28 Nov 2004 14:22:32 -0800 (PST)
Received: (from www@localhost)
	by phaenicia.ucdavis.edu (8.12.10/8.12.9/Submit) id iASMMVNR009820;
	Sun, 28 Nov 2004 14:22:31 -0800 (PST)
Date: Sun, 28 Nov 2004 14:22:31 -0800 (PST)
Message-Id: <200411282222.iASMMVNR009820@phaenicia.ucdavis.edu>
To: fanzhao@ucdavis.edu
Subject: Call for Papers: IEEE JSAC MRNM
From: "Fan Zhao" <fanzhao@ucdavis.edu>
Cc: manet@ietf.org, nemo@ietf.org, mip6@ietf.org, hipsec@honor.trusecure.com,
        mip4@ietf.org, mipshop@ietf.org, multi6@ops.ietf.org,
        v6ops@ops.ietf.org, mobopts@irtf.org
X-Errors-To: fanzhao@blue.ucdavis.edu
X-Mailer: Geckomail-b16
X-Originating-IP: [128.120.178.196]
X-User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
X-Scanned-By: MIMEDefang 2.41
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham 
	version=3.0.1
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk


       PLEASE ACCEPT OUR APOLOGIES IF YOU RECEIVE MULTIPLE COPIES       

                            CALL FOR PAPERS                            
            IEEE Journal on Selected Areas in Communications            
                  MOBILE ROUTERS AND NETWORK MOBILITY                  

  http://www.argreenhouse.com/society/J-SAC/Calls/mobile_routers.html

Network mobility support is concerned with managing the mobility of an 
entire network that is changing its point of attachment to the Internet 
and thus its reachability in the Internet topology. If network mobility 
is not explicitly supported by some mechanisms, existing sessions break 
and connectivity to the global Internet is lost. A mobile network is 
composed of Mobile Router(s) (MR) and Mobile Network Nodes (MNN) that 
can be fixed or mobile. There has been rapid development in network 
mobility support, i.e., providing Internet connectivity to the networks 
that move using mobile routers since the inception of Mobile IPv4 in 
1996. Seamless Internet access in public transportation such as in 
trains and busses can be possible if mobile routers are used. Cars with 
low-power sensors seamlessly connected to the Internet constitute yet 
another example of networks which move. To date, some airline companies 
announced Internet connectivity support during commercial flights and 
this trend is expected to accelerate and cover most if not all flights. 

This issue is focused on modeling, analysis, and simulation of network 
mobility support protocols. We solicit papers presenting original and 
unpublished work including, but not limited to the following topics: 

* Modeling and Analysis of Network Mobility 
    o Modeling, analysis and simulation of mobile router 
    o Protocols for route optimization 
    o Mobility issues inside a mobile network 
    o Mobile IPv6 extensions for route optimization 
    o Nested mobile networks 
    o Multihomed mobile networks 
    o Operational issues to deploy mobile networks 
    o Auto-configuration for mobile networks 
    o Mobile router support on cellular phone platforms 

* Services in the Networks that Move 
    o Service advertisement and discovery protocols in networks that
      move 
    o Specifications and models of services for network mobility 
    o Encryption and authentication in service access for network
      mobility 

* Security Issues in Network Mobility 
    o Security analysis of present network mobility support protocols 
    o Applications of AAA and EAP to network mobility 
    o Interaction with security-enhanced modules in other layers 
      (vertically) or other middle boxes (horizontally) 

Prospective authors should follow the IEEE J-SAC manuscript format 
described in the Information for Authors. Authors MUST submit their 
draft manuscripts through the EDAS peer review website, together with a 
short abstract (approximately 150 words) in the EDAS website form. 
Please note potential authors should create their own accounts through 
the EDAS peer review website before submitting manuscript(s). EDAS will 
accept manuscripts in PDF format only. There will be one round of 
reviewers and acceptance will be limited to those papers requiring only 
moderate revisions. The following timetable applies: 

Manuscript Submission: JUNE 1, 2005
Acceptance Notification: December 1, 2005
Final Manuscript Due: March 1, 2006
Publication: 3rd Quarter 2006

Guest Editorial Board: 

Behcet Sarikaya
Computer Science Dept
Univ of Northern British Columbia
Prince George, BC
Canada V2N 4Z9
sarikaya@unbc.ca

S. Felix Wu
Dept of Computer Science
Univ of California at Davis
Davis, CA 95616 USA
wu@cs.ucdavis.edu

Gopal Dommety
Cisco Systems, Inc
170 West Tasman Dr
San Jose, CA 95134-1706 USA
gdommety@cisco.com

Claude Castelluccia
INRIA Rhône-Alpes ZIRST
655 Ave de l'Europe
Montbonnot
38334 Saint Ismier cedex
France
claude.castelluccia@inria.fr

Thierry Ernst
Jun Murai Lab
Keio Univ K-square
Town Campus
1488-8 Ogura, Saiwai-ku,
Kawasaki, Kanagawa 212-0054
Japan
ernst@sfc.wide.ad.jp

Charles E. Perkins
Communication Systems Lab
Nokia Research Center
313 Fairchild Dr
Mountain View, CA 94943 USA
charliep@iprg.nokia.com




From owner-v6ops@ops.ietf.org  Mon Nov 29 01:25:11 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04141
	for <v6ops-archive@lists.ietf.org>; Mon, 29 Nov 2004 01:25:10 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
	id 1CYevX-000JQp-FO
	for v6ops-data@psg.com; Mon, 29 Nov 2004 06:22:23 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.43 (FreeBSD))
	id 1CYevW-000JQb-Da
	for v6ops@ops.ietf.org; Mon, 29 Nov 2004 06:22:22 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id iAT6MLj26674
	for <v6ops@ops.ietf.org>; Mon, 29 Nov 2004 08:22:21 +0200
Date: Mon, 29 Nov 2004 08:22:21 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: v6ops@ops.ietf.org
Subject: Take VLAN usage as WG document?
Message-ID: <Pine.LNX.4.61.0411290816370.26365@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.0.1
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

Hi,

(co-chair hat on)

The author has asked if the document describing usage of VLANs 
for IPv6 deployed could be taken as a WG document:

http://www.ietf.org/internet-drafts/draft-chown-v6ops-vlan-usage-02.txt

This is in the charter, and useful as an Informational document.

Please say what you think.  Silence DOES NOT indicate consent.  If new 
work items are to be adopted, there must be active support for doing 
it, and there must be people willing to review and work on the draft.

The deadline for comments is in about 1.5 weeks, on December 8th.

(hat off)

-- 
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 owner-v6ops@ops.ietf.org  Mon Nov 29 05:17:45 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02789
	for <v6ops-archive@lists.ietf.org>; Mon, 29 Nov 2004 05:17:44 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
	id 1CYiYF-000E2M-Ny
	for v6ops-data@psg.com; Mon, 29 Nov 2004 10:14:35 +0000
Received: from [144.254.15.119] (helo=strange-brew.cisco.com)
	by psg.com with esmtp (Exim 4.43 (FreeBSD))
	id 1CYiYD-000E1d-10
	for v6ops@ops.ietf.org; Mon, 29 Nov 2004 10:14:33 +0000
Received: from gvandeve-w2k01.cisco.com (dhcp-lisbon-vlan10-64-103-21-87.cisco.com [64.103.21.87])
	by strange-brew.cisco.com (8.11.7p1+Sun/8.8.8) with ESMTP id iATAEH102781;
	Mon, 29 Nov 2004 11:14:21 +0100 (CET)
Message-Id: <4.3.2.7.2.20041119214322.02b5ad08@strange-brew>
X-Sender: gvandeve@strange-brew
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 29 Nov 2004 10:31:26 +0100
To: Tim Chown <tjc@ecs.soton.ac.uk>
From: "Gunter Van de Velde (gvandeve)" <gvandeve@cisco.com>
Subject: Re: Comments on draft-vandevelde-v6ops-nap-00
Cc: v6ops@ops.ietf.org
In-Reply-To: <20041108125055.GA31930@login.ecs.soton.ac.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham 
	version=3.0.1
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

At 12:50 8/11/2004 +0000, Tim Chown wrote:
>Overall, very nice thrust :)
>
>
>    has some perceived benefits.  Indeed, in an Internet model based on
>    universal any-to-any connectivity, product marketing departments have
>    driven a perception that some connectivity and security concerns can
>    only be solved by using a NAT device or by using logically separated
>    LAN address spaces.
>
> >> But it's not any-to-any, is it?  Maybe "originally based on the concept
>    of universal any-to-any connectivity, this concept has been stifled by
>    product marketing departments who have sold consumers a perception..."
>    (and as a result, we have an Internet of consumers...)

it is not any-to-any, but nevertheless initially that was the concept.=20
Would be nice
if IPv6 could bring it back closer to reality

>    This document describes the market perceived
>    reasons to utilize a NAT device in an IPv4 environment and shows how
>    these needs can be met and even exceeded with native IPv6.  The use
>
> >> What do you mean by "native" here?  (some readers may not know)

Various way to address this. One solution is to get definition summary
in the document.

>    This document describes several techniques that may be combined on an
>    IPv6 site to protect the integrity of its network architecture.
>    These techniques, known collectively as NAP, retain the concept of a
>    well defined boundary between "inside" and "outside" the private
>    network, and allow firewalling, topology hiding, and privacy and
>    achieve these goals without address translation.
>
> >> Are we concerned with address translation here, or use of private (site
>    local) addresses?   The latter has no translation, but may leak...

It is a combination technologies as described. No translation with NAP=20
though :-)
The leaking should be solved with ULA as they may not be used to neighboring
administrative domains. (its still being discussed if this should be=20
hard-coded or
filtered by policy i believe)

>2.  Perceived benefits of NAT and its impact on IPv4
>
>2.2  Simple security due to stateful filter implementation
>
>    It is frequently believed that a NAT device puts in an extra barrier
>    to keep the private network protected from evil outside influences
>    due to the stateful character of NAT technology (to protect against
>    hackers, worms, etc..).
>
> >> I'd not say "evil" even if it is :)

It seems to make the text a bit more alive :-)

> >> Also, "stateful" isn't the thing, it's that the internal (private)
>    addresses cannot (usually) be routed to/contacted from outside the
>    private network.

I think that is a question of terminology. your definition is the same as=20
my understanding
with that difference that the routing device has a translation slot created
due to the stateful character, hence the stateful aspect is the root-cause
why external devices can not access 'all' internal devices

>    This benefit may be partially real; however,
>    experienced hackers are well aware of NAT devices and are very
>    familiar with the private address space, and hence the secure feeling
>    is in vain.
>
> >> A little wooly; perhaps specify the vulnerability in more detail.
>
>    Address translation does not provide security on itself; for example,
>    consider a configuration with static NAT translation and all ports
>    translating to a single machine.  In such a scenario the security
>    risk for that machine is identical as if there were no NAT device in
>    the communication path.  As result there is no specific security
>    value in the address translation function.  The perceived security
>    comes from the lack of pre-established mapping state.  Dynamically
>    establishing state in response to internal requests reduces the
>    threat of unexpected external connections to internal devices.
>
> >> And of course many vulnerabilities these days are not from IP-based
>    connections into a network, but from data received by the network
>    (emails, images, web pages, etc).   NAT is just a piece of the picture.

correct. A note is added in the Working document for creating -01 draft.

> >> Some NAT users will also map ports to enable services into their
>    NATed network; here the NAT adds complexity; not sure that's captured
>    in the draft?

thats right. Main goal is to focus on the positive aspects on why people
use NAT (time to completion) and see how it can be achieved with
IPv6 without address translation. I'm not sure where to add this yet.

>2.3  User/Application tracking
>
>    Due to the fact that NAT is a stateful technology, it could provide
>    limited capabilities for the administrator of the NAT to gather
>    information about who in the private network is requesting access to
>    which Internet location.  This can be done by checking the network
>    address translation details of the private and the public addresses
>    of the NAT devices state-database.
>
> >> But this can be done (and is done) with non-NATed networks?.

true. When using NAT it could provide additional chunk of information
on top of that.

>2.4  Privacy and topology hiding
>
>    The ability NAT to provide internet access by the use of a single (or
>    few) global IPv4 routable addresses to a large community of users
>    offers a simple mechanism to hide the internal topology of a network.
>    In this example the large community will be reflected in the internet
>    by a single (or few) IPv4 address(es).
>
>    The use of NAT then results in a user behind a NAT gateway actually
>    appearing on the Internet as a user inside the NAT box itself; i.e.,
>    the IPv4 address that appears on the Internet is only sufficient to
>    identify the NAT.  Thus it is impossible to tell from the outside
>    which member of a family, which customer of an Internet caf=C3=A2, or
>    which employee of a company generated or received a particular
>    packet, if concealed behind NAT.  Thus, although NATs do nothing to
>    provide application level privacy, they do prevent the external
>    tracking and profiling of individual host computers by means of their
>    IP addresses.  At the same time it creates a smaller pool of
>    addresses for a much more focused point of attack.
>
> >> There is a similarity with app-level, in that a NAT offers similar
>    "privacy" for web users as a web cache (although the details of what
>    is - or is not - logged at the NAT/proxy will be deifferent).

added the text

>    Some enterprises prefer to hide as much as possible of their internal
>    network topology from outsiders.  Mostly this is achieved by blocking
>    "traceroute" etc., but NAT of course entirely hides the internal
>    subnet topology, which some network managers believe is a useful
>    precaution to mitigate scanning attacks.
>
> >> Perhaps talk somewhere about two-faced DNS, which is used to
>    support this model.
>
> >> Also scanning in v6 can be much harder, by obscurity (see
>    draft-chown-v6ops-port-scanning-implications-01)

Added reference to the this draft.

>2.5  Independent control of addressing in a private network
>
>    Due to the ongoing depletion of the IPv4 address range, the remaining
>    pool of unallocated IPv4 addresses is below 30%.  Recent consumption
>    rates are over 7% of the total IPv4 space per year.  This run rate
>    leaves about 4 years to deplete the remaining unallocated pool.
>
> >> Recent IETF list discussion would "debate" these numbers :)

ack

>    Many private IPv4 networks take benefit from using the address space
>    defined in RFC 1918 to enlarge the available addressing space for
>    their private network, and at the same time reduce their need for
>    globally routable addresses.  This type of local control of address
>    resources allow a clean and hierarchical addressing structure in the
>    network.
>
> >> But v6 addressing for the enterprise is a /48 (in effect a Class A
>    of v4 address space, but with 2^64 hosts per subnet not 2^8).

agree.

> >> With v6, you are far less likely to need to go back to ask for more
>    address space (with the paperwork that goes with that).

agree

> >> With v6, you don't have to resize subnets to use v4 address space
>    efficiently; an enterprise today may have a mix of /28 - /23 size
>    subnets for example, and may shrink/grow these as their network
>    user base/etc changes.  In v6, it's all /64.

Good note. It will be added.

>    Another benefit is due to the usage of independent addresses on
>    majority of the network infrastructure there is an increased ability
>    to change provider with less operational difficulties.
>
> >> This is a BIG plus for v4 today; no PI addressing in v6.

yep, that is discussed in later chapter

>2.6.1  Medium/large private networks
>
>    Under this category fall the majority of private enterprise networks.
>    Many of these networks have one or more exit points to the Internet.
>    There are several reasons why NAT be be used in such a network.  For
>
> >> "be be" -> "may be"
>
>    the ISP there is no need to import the IPv4 address range from the
>    remote end-customer, which facilitates IPv4 address summarization.
>    The customer can use a larger IPv4 address range (probably with
>    less-administrative overhead) by the use of RFC 1918 and NAT.  The
>    customer also reduces the overhead in changing to a new ISP, because
>    the addresses assigned to devices behind the NAT do not need to be
>    changed when the customer is assigned a different address by a new
>    ISP.  Finally, the customer can provide privacy about its hosts and
>    the topology of its internal network if the internal addresses are
>    mapped through NAT.
>
> >> So be more explicit and say "using NAT avoids the need for network
>    renumbering" and that "NAT can help support IPv4 site multihoming"
>    (though of course both solutions have restrictions and come at a
>    price)   You do mention this further down, I note,

agree. adapted some wording here.

>2.6.3  Single user connection
>
>    This group identifies the users which are connected via a single IPv4
>    address and use a single piece of equipment (PC, PDA, etc.).  This
>    user may get an ambiguous IPv4 address from the service provider
>    which is based on RFC 1918.  If ambiguous addressing is utilized, the
>    service provider will execute NAT on the allocated IPv4 address for
>    global Internet connectivity.  This also limits the internet
>    capability of the equipment to being mainly a receiver of Internet
>    data, and makes it quite hard for the equipment to become a world
>    wide internet server (i.e.  HTTP, FTP, etc.) due to the stateful
>    operation of the NAT equipment.
>
> >> Or you have a SOHO user with one NAT device (e.g. cable modem) and
>    only one home PC.   That's different to receiving a private v4
>    address that is NATed higher up the ISP network.

Correct. This is more the small enterprise example. We will prob. change
this section in a case study in next release.

> >> Also in Section 3, maybe mention that NAT is often not a customer
>    choice; it's frequently imposed by the ISP, or deployed because the
>    organisation outsourced its IT.

will add the note

> >> Is there an (obvious) new subsection for the case where the deploying
>    network for some reason feels it is unable to get enough global v4
>    address space, or the scenario is one where the number of attaching
>    nodes is unknown (e.g. a WLAN provision at a conference or hotel?)

ok. We will discus this further

>3.  Description of the IPv6 tools
>
>    This section describes several features that can be used to provide
>    the protection features associated with IPv4 NAT.
>
>3.1  Privacy addresses (RFC 3041)
>
>    There is nothing that prevents a DHCP server from running RFC 3041
>    for any new MAC it hears, then remembering that for future queries.
>    This would allow using them in DNS for registered services since the
>    assumption would be a persistent value that minimizes DNS churn.
>
> >> Any comment on the RFC3041-considered-harmful viewpoint here?
>
> >> 3041 is very like v4 NAT in that 3041 doesn't protect the subnet ID
>    just as NAT doesn't protect the v4 global address used.

added note for discussion for -01 version.

>3.2  Unique Local Addresses
>
>    A unique local address (ULA) is an IPv6 unicast address format that
>    is globally unique and is intended for local communications [12].
>    These are expected NOT to be routed on the global Internet.  They are
>    routable inside of a more limited area defined by a local network
>    administrator.
>
> >> Note also draft-ietf-ipv6-ula-central-00, i.e. the ULA itself may
>    not be unique, whereas the centrally assigned prefixes should be.
>    For sites looking to merge without use of NAT, the central method
>    would give a greater assurance of no clash.

ok, agree. Some text is added.

>3.4  Untraceable IPv6 addresses
>
>    These are globally routable IPv6 addresses which can be randomly and
>    dynamically assigned to IPv6 devices and are globally aggregatable
>    addresses assigned to the local network by either a registry or
>    connecting ISP.  The random assignment has as purpose to confuse the
>    outside world on the structure of the local network, while for the
>    local network the location of the randomly assigned IPv6 address is
>    known and connectivity inside the local network can exist.  The goal
>    is to create a network infrastructure which appears from external
>    networks with an unpredictable structure, to avoid malicious events
>    to happen to the local network.  When using untraceable IPv6
>    addresses, it may be that two apparently sequential addresses are
>    reachable on very different parts of the local network instead of
>    belonging to the same subnet next to each other.
>
> >> Is there a reference to this?  I'm not sure how this would actually
>    be implemented, or of the drawbacks of doing so.
>
> >> Maybe "infinitely" sized subnets are an IPv6 "tool", in that a
>    subnet can absorb any number of hosts (in theory at least) without
>    subnet resizing or needing to NAT (if the network had a Class C v4
>    and might have more than 253 nodes attaching simultaneously).
>
> >> Related is the issue of dynamic vs static address allocation; does
>    the same node get the same IP address when attaching each time, or
>    to conserve (v4) address space is the address dynamic?   If a
>    network has a Class C v4 and has 1,000 users of whom only 100 may
>    be attached at any one time, in v4 you need dynamic addressing,
>    in v6 you don't.

We will rewrite some part of this section to clear up some dymistification.

>4.1  Simple gateway between Internet and internal network
>
>    The connection creation towards the global Internet hosts/systems
>    will always happen with global IPv6 addresses.  An enterprise will
>    typically receive a global IPv6 address prefix from his connecting
>    IPv6 Service Provider.
>
> >> "his" -> "its"
>
>4.2  IPv6 and Simple security
>
>    The vulnerability of an IPv6 host is similar as for an IPv4 host
>    directly connected towards the Internet, and firewall and IDS systems
>    are recommended.  However, with IPv6, the following protections are
>    available without the use of NAT:
>
>    1.  Short lifetimes on privacy extension suffixes reduce the attack
>        profile since the node will not respond to the address once the
>        address is no longer valid.
>
> >> Important because with port-scanning very hard to do in v6, attackers
>    will need to gather target addresses from various server log files,
>    and then try these.
>
>    2.  IPsec is a mandatory service for IPv6 implementations.  IPsec
>        functions to prevent session hijacking, prevent content
>        tampering, and optionally masks the packet contents.  While IPsec
>        might be available in IPv4 implementations, deployment in NAT
>        environments either breaks the protocol or requires complex
>        helper services with limited functionality.
>
> >> Or significant compromises in trust.
>
>    3.  The size of the typical subnet ::/64 will make a network ping
>        sweep and resulting port-scan virtually impossible due to the
>
>
>
>Van de Velde, et al.     Expires April 12, 2005                [Page 11]
>Internet-Draft    IPv6 Network Architecture Protection      October 2004
>
>
>        amount of possible combinations available
>
> >> See the port-scanning draft :)
>
>    This simple rule would create similar protection and security holes
>    the typical IPv4 NAT device will offer and may for example be enabled
>    by default on all broadband edge-routers.  but with that difference
>    that the security caveats will be documented, and may hence be
>    removed with the next revision of the rule.  The goal is that every
>    iteration, the IPv6 internet will become more secure for the
>    oblivious users.
>
> >> The snag is configuring this in home networking scenarios (for example)
>    where today NAT "does the job"; as we require network access into the
>    home, how do we let Joe User say "my PDA can access my home DVR?".
>
>    unrealistic) pings to map the network, and virus/worm propagation
>    will be thwarted in the process At full rate 40Gbps (400 times the
>    typical 100Mbps LAN, and 13,000 times the typical DSL/Cable access
>    link) it takes over 5000 years to scan a single 64 bit space.
>
> >> Again, see the port-scanning draft.   You may find other notes worth
>    reusing in there.

ok


>4.4  Privacy and topology hiding using IPv6
>
>    By using untraceable addresses, it is possible to only allocate
>    certain parts of the internal network with global prefixes, while
>    other, private network parts do not have global prefixes and remain
>    totally cut off from the outside.  If an edge firewall is used (which
>    is strongly suggested) a traffic policy can be implemented as today,
>    based on various filtering and inspection rules.  (Older techniques
>    such as application level proxies and SOCKS also remain available.)
>
> >> Worth mentioning (two-faced) DNS issues here?

Maybe... i'll add note and check what the other believe is best?

>    If there is need to mask the internal structure towards the external
>    IPv6 internet, then the usage of 'Untraceable' addresses may be used.
>    These addresses will be derived from a local pool, and may be
>    assigned to those hosts for which topology masking is required or
>    which want to reach the IPv6 Internet or other external networks.
>
> >> I think a separate I-D on "untraceable" addresses might be useful?

Sounds like a good idea. It would be good to have broader study on the
feasability of such a technology.

>    The technology to assign these addresses to the hosts could be based
>    on DHCPv6.  To complement the 'Untraceable' addresses it is needed to
>    have at least awareness of the IPv6 address location when routing an
>    IPv6 packet through the internal network.  This could be achieved by
>    'route-injection' in the network infrastructure.  This
>    route-injection could be done based on ::/128 host-routes to each
>    device that wants to connect to the Internet.
>
> >> I think you make a good point about scalability; need to have some
>    clearer idea of the tradeoffs here?  (or in the separate I-D)
>
>4.6.2  small private networks
>
>    The category describes those networks which only have only few
>    routers in the topology, and have a single network egress point.
>    These networks are also known as SOHO (Small Office/Home Office)
>    networks.  Typically these networks don't have dedicated Network
>    Operation Center (NOC) and are using either a dial-up connection or
>    broadband access..
>
> >> Most SOHO networks are single (access) router networks?

i believe so... does your home-office have dual connection? Mine does not=
 not.

>4.6.4  ISP/Carrier customer networks
>
>    This group refers to the actual service providers that are providing
>    the IP access.  They tend to have three separate IP domains that they
>    support.  For the first they fall into the Medium/large private
>    networks category (above) for their own internal networks, LANs etc.
>    and will be able to use the same solutions as above.  The second is
>    their Operations network which addresses their backbone and access
>    switches, and other hardware, this is separate for both engineering
>    reasons as well as simplicity in managing the security of the
>    backbone, for this it is again possible to configure a single range
>    of addresses with the defined local scope defined in order to prevent
>    these from being accessed from the public network.  The third is the
>    IP addresses (single or blocks) that they assign to customers.  These
>    can be registered addresses (usually given to category a and b and
>    sometimes c) or can from a pool of RFC 1918 addresses used with NAT
>    for single user connections.  Therefore they can actually have two
>    different NAT domains that are not connected (internal LAN and single
>    user customers) again this will be resolved by the large availability
>    of addresses and the procedures mentioned above.
>
> >> So the main gain is simplified network management for the operator?
>    Or something else?   Might be useful to make it clear.

added note for -01 draft update

>4.7  Multihoming and renumbering
>
>    The IPv6 address space allocated by the ISP will be dependent upon
>    the connecting Service provider.  This may result in a renumbering
>    effort if the enterprise changes from Service Provider.  To keep the
>
> >> "from" -> "its"
>
>    impact on the gateway when changing ISP to a zero human touch
>    environment, DHCPv6 Prefix Delegation [10] can be used.
>
> >> You might want to cite Fred's draft here if you don't already, and
>    also draft-chown-v6ops-renumber-thinkabout-00.   One specific
>    scenario to add here for renumbering might be network mergers?

Freds draft is included. The -renumber-thinkabout-00 was not. Will add the
suggested reference.

>5.  Additional benefits due to Native IPv6 and universal unique
>    addressing
>
>    Is all of the material in this section, specifically the material
>    that does not directly address the "advantages" of IPv4 NAT,
>    necessary?
>
> >> It is useful to document somewhere;  perhaps split into two sections,
>    one in poker terms that "sees" IPv4 NAT, and one that raises the bet
>    with IPv6?

added your vote :-)

>5.1  Universal any-to-any connectivity
>
>    One of the original design points of the Internet was any-to-any
>    connectivity.  The dramatic growth of Internet connected systems
>    coupled with the limited address space of the IPv4 protocol spawned
>    address conservation techniques.  NAT was introduced as a tool to
>    reduce demand on the limited IPv4 address pool, but the side effect
>    of the NAT technology was to remove the any-to-any connectivity
>    capability.  By removing the need for address conservation (and
>    therefore NAT), IPv6 returns the any-to-any connectivity model and
>    removes the limitations on application developers.  With the freedom
>    to innovate unconstrained by NAT traversal efforts, developers will
>    be able to focus on new advanced network services (i.e.  peer-to-peer
>    applications, IPv6 embedded IPsec communication between two
>    communicating devices, instant messaging, Internet telephony, etc..)
>    rather than focusing on discovering and traversing the increasingly
>    complex NAT environment.
>
> >> There are some good "transparency" type RFCs from Brian and others
>    that could be cited here.   2775 springs to mind.   Also RFC on
>    implications of using NAT - 2993 I think.

some are reference already. Will check with Brian.

>5.2  Auto-configuration
>
>    IPv6 offers a scalable approach to minimizing human interaction and
>    device configuration.  Whereas IPv4 implementations require touching
>    each end system to indicate the use of DHCP vs.  a static address and
>    management of a server with the pool size large enough for the
>    potential number of connected devices, IPv6 uses an indication from
>    the router to instruct the end systems to use DHCP or the stateless
>    auto configuration approach supporting a virtually limitless number
>    of devices on the subnet.  This minimizes the number of systems that
>    require human interaction as well as improves consistency between all
>    the systems on a subnet.  In the case that there is no router to
>    provide this indication, an address for use on the local link only
>    will be derived from the interface media layer address.
>
> >> Not sure about this.  Most OSes will do DHCP(v4) by default today,
>    when connecting.  So "autoconfiguration" is there, but it requires
>    DHCP to be set up somewhere by the "provider".   How widely used
>    is the IPv4 link-local equivalent under 169. - seems to be mainly
>    a Microsoft implemented mechanism?

added note for discussion of -01 draft

>5.3  Native Multicast services
>
>    Multicast services in IPv4 were severely restricted by the limited
>    address space available to use for group assignments and an implicit
>    locally defined range for group membership.  IPv6 multicast corrects
>    this situation by embedding explicit scope indications as well as
>    expanding to 4 billion groups per scope.  In the source specific
>    multicast case, this is further expanded to 4 billion groups per
>    scope per subnet by embedding the 64 bits of subnet identifier into
>    the multicast address.
>
>    IPv6 allows also for innovative usage of the IPv6 address length, and
>    makes it possible to embed the multicast 'Rendez-Vous Point' (or RP)
>    directly in the IPv6 multicast address when using ASM multicast.
>    this is not possible with limited size of the IPv4 address.
>
> >> Cite Pekka's work on this?
>
> >> Also make a comment about SSM and IPv6?   There seems to be a strong
>    feeling that IPv6 is an opportunity to get SSM deployed more widely
>    with its more streamlined architecture.

added note for -01 discussion.

>5.4  Increased security protection
>
>    The security protection offered by native IPv6 technology is more
>    advanced as with IPv4 technology.  There are various transport
>
> >> "as with" -> "than"?
>
>    mechanisms enhanced to allow a network to operate more secure with
>    less performance impact:
>
> >> "secure" -> "securely"
>
>    o  On a local network, any user will have more security awareness.
>       This awareness will motivate the usage of simple firewall
>       applications/devices to be inserted on the border between the
>       external network and the local (or home network).
>
> >> I don't think users will be more security aware with IPv6, if they
>    even know they're using IPv6.  I think with growing use of shared
>    hotspots etc we'll see growing awareness of personal firewalls in
>    general.
>
>    o  The usage of private address-space in IPv6 still provides with
>
> >> "is now provided by"

ok

>       Unique Local Addresses, which will avoid conflict situations when
>       joining networks and securing the internal communication on a
>
> >> "joining" -> "merging"

ok

>       local network infrastructure due to simpler traffic filtering
>       policy
>
>5.5  Mobility
>
>    Anytime, anywhere, universal access requires mIPv6 services in
>
> >> "MIPv6"

yep. it is changed now. should be for all instances of MIPv6 in the draft.

>    support of mobile nodes.  While a Home Agent is required for initial
>    connection establishment in either protocol version, IPv6 mobile
>    nodes are able to optimize the path between them using the mIPv6
>
> >> "MIPv6"
>
>    option header while IPv4 mobile nodes are required to triangle route
>    all packets.  In general terms this will minimize the network
>    resources used and maximize the quality of the communication
>
> >> eg. very useful when two mobile nodes in same WLAN with low bandwidth
>    uplink what to share data, to avoid the data passing over the uplink.
>
>5.6   Merging networks
>
>    With the usage of IPv6 the addressing overlap will not exist because
>    of the existence of the Unique Local Address usage for private and
>    local addressing.
>
> >> As per above, note the difference between the two variants of ULA, one
>    centrally assigned.
>
>5.7  Community of interest
>
>    Although some Internet-enabled devices will function as fully-fledged
>    Internet hosts, it is believed that many will be operated in a highly
>    restricted manner functioning largely or entirely within a Community
>    of Interest.  By Community of Interest we mean a collection of hosts
>    that are logically part of a group reflecting their ownership or
>    function.  Typically, members of a Community of Interest need to
>    communicate within the community but should not be generally
>    accessible on the Internet.  They want the benefits of the
>    connectivity provided by the Internet, but do not want to be exposed
>    to the rest of the world.  This functionality will be available
>    through the usage of NAP and native IPv6 dataflows, without any
>    stateful device in the middle.
>
> >> Also maybe talk about virtual organisation networks built on the fly?
>    Very difficult to do in IPv4+NAT scenarios.   The nodes may also
>    take part in other communications in general.

TWhat do you exactly mean with this? How do you see this model of
virtual organisations?

>6.  IPv6 gap analysis
>
>6.3  Minimal traceability of privacy addresses
>
>    Privacy addresses (RFC 3041) may certainly be used within the
>    enterprise to limit the traceability of external traffic flows, but
>    they would still reveal the subnet address bits.  To eliminate this,
>    some combination of privacy addresses with the previous two points is
>    required, and this work remains to be done.
>
> >> The use of privacy addresses is also itself generally detectable.
>
>6.4  Renumbering procedure
>
>    Documentation of site renumbering procedures [11] should be
>    completed.  It should also be noticed that ULAs will help here too,
>    since a change of ISP prefix will only affect hosts that need an
>    externally routeable address as well as a ULA.
>
> >> Also draft-chown-v6ops-renumber-thinkabout-00.   Are there downsides
>    to using ULAs?  If so, these are not described in this text.  e.g. it
>    requires all nodes to implement address selection as desired (favour
>    ULA src for ULA dst, global src for global dst, etc).


>6.6  Untraceable addresses
>
>    The details of the untraceable addresses, along with any associated
>    mechanisms such as route injection, must be worked out and specified.
>
> >> A new I-D on this would be good.
>
> >> What about a set of recommendations for a site?  Like "use ULAs if
>    you want feature X", or is this just implied already?

it should be implied already. I hope the case study examples will make=20
thinks more clear.

Cheers, and many thanks for the feedback. We have now many notes, together=
=20
with our own
planned changes in the -00 draft to get to an enhanced -01 document.

Brgds,
G/




From owner-v6ops@ops.ietf.org  Mon Nov 29 06:15:13 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06936
	for <v6ops-archive@lists.ietf.org>; Mon, 29 Nov 2004 06:15:03 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
	id 1CYjTw-00024p-9b
	for v6ops-data@psg.com; Mon, 29 Nov 2004 11:14:12 +0000
Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk)
	by psg.com with esmtp (Exim 4.43 (FreeBSD))
	id 1CYjTv-00024c-6e
	for v6ops@ops.ietf.org; Mon, 29 Nov 2004 11:14:11 +0000
Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131])
	by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id iATBEAi3004716
	for <v6ops@ops.ietf.org>; Mon, 29 Nov 2004 11:14:10 GMT
Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162])
	by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id LAA12200
	for <v6ops@ops.ietf.org>; Mon, 29 Nov 2004 11:14:08 GMT
Received: (from tjc@localhost)
	by login.ecs.soton.ac.uk (8.11.6/8.11.6) id iATBE8g31401
	for v6ops@ops.ietf.org; Mon, 29 Nov 2004 11:14:08 GMT
Date: Mon, 29 Nov 2004 11:14:08 +0000
From: Tim Chown <tjc@ecs.soton.ac.uk>
To: v6ops@ops.ietf.org
Subject: Re: Take VLAN usage as WG document?
Message-ID: <20041129111408.GH30474@login.ecs.soton.ac.uk>
Mail-Followup-To: v6ops@ops.ietf.org
References: <Pine.LNX.4.61.0411290816370.26365@netcore.fi>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.61.0411290816370.26365@netcore.fi>
User-Agent: Mutt/1.4i
X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information
X-ECS-MailScanner: Found to be clean
X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.0.1
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

On Mon, Nov 29, 2004 at 08:22:21AM +0200, Pekka Savola wrote:
> Hi,
> 
> (co-chair hat on)
> 
> The author has asked if the document describing usage of VLANs 
> for IPv6 deployed could be taken as a WG document:
> 
> http://www.ietf.org/internet-drafts/draft-chown-v6ops-vlan-usage-02.txt
> 
> This is in the charter, and useful as an Informational document.
> 
> Please say what you think.  Silence DOES NOT indicate consent.  If new 
> work items are to be adopted, there must be active support for doing 
> it, and there must be people willing to review and work on the draft.
> 
> The deadline for comments is in about 1.5 weeks, on December 8th.

The technique described is one that is being widely used, at least in
European academic environments.   It is, to many people, a fairly obvious
method to use to enable dual-stack networking via a parallel IPv6 routed
infrastructure, but since many people have also asked how it is done, otr
why, this document was written.

The scenario it addresses is structured/managed IPv6 deployment per link
in a network with no production/commercial IPv6 routing equipment available;
in the case of existing networks using the technique, Linux/BSD routers
are used.

-- 
Tim



From owner-v6ops@ops.ietf.org  Mon Nov 29 10:24:58 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00863
	for <v6ops-archive@lists.ietf.org>; Mon, 29 Nov 2004 10:24:58 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
	id 1CYnLZ-000AsB-Gl
	for v6ops-data@psg.com; Mon, 29 Nov 2004 15:21:49 +0000
Received: from [195.30.1.100] (helo=moebius2.Space.Net)
	by psg.com with smtp (Exim 4.43 (FreeBSD))
	id 1CYnLV-000Aio-7t
	for v6ops@ops.ietf.org; Mon, 29 Nov 2004 15:21:45 +0000
Received: (qmail 27058 invoked by uid 1007); 29 Nov 2004 15:21:44 -0000
Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=testkey; d=space.net;
  b=QP2p7BAQSJqekFVaNFtTr0INk0rvQR8Vf/9QAltLwLERfaUqb1RSFI/4cW6EUlGQ  ;
Date: Mon, 29 Nov 2004 16:21:44 +0100
From: Gert Doering <gert@space.net>
To: Pekka Savola <pekkas@netcore.fi>
Cc: v6ops@ops.ietf.org
Subject: Re: Take VLAN usage as WG document?
Message-ID: <20041129152144.GK84850@Space.Net>
References: <Pine.LNX.4.61.0411290816370.26365@netcore.fi>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.61.0411290816370.26365@netcore.fi>
User-Agent: Mutt/1.4.1i
X-NCC-RegID: de.space
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.0.1
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

Hi,

On Mon, Nov 29, 2004 at 08:22:21AM +0200, Pekka Savola wrote:
> (co-chair hat on)
> 
> The author has asked if the document describing usage of VLANs 
> for IPv6 deployed could be taken as a WG document:
> 
> http://www.ietf.org/internet-drafts/draft-chown-v6ops-vlan-usage-02.txt
> 
> This is in the charter, and useful as an Informational document.

I think it would make a useful informational document.

Personally, I find this approach "obvious" - but that's only because 
I've already been through the process of wondering how to bring IPv6 to
our VLAN infrastructure (which was served by a VLAN router that was
conveniently declared as "End of Life" just one OS release before
the general introduction of IPv6), and ended up doing it exactly
this way - the existing IPv4 router stays, a new box for IPv6 only
VLAN routing is built (which is not as powerful as the IPv4 router, but
sufficient for v6).

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  66629  (65398)

SpaceNet AG                 Mail: netmaster@Space.Net
Joseph-Dollinger-Bogen 14   Tel : +49-89-32356-0
80807 Muenchen              Fax : +49-89-32356-299




From owner-v6ops@ops.ietf.org  Mon Nov 29 23:57:20 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21205
	for <v6ops-archive@lists.ietf.org>; Mon, 29 Nov 2004 23:57:20 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
	id 1CZ020-0008yg-Fc
	for v6ops-data@psg.com; Tue, 30 Nov 2004 04:54:28 +0000
Received: from [132.151.6.71] (helo=megatron.ietf.org)
 	by psg.com with esmtp (Exim 4.43 (FreeBSD))
 	id 1CYtru-000OFO-42
 	for v6ops@ops.ietf.org; Mon, 29 Nov 2004 22:19:38 +0000
Received: from apache by megatron.ietf.org with local (Exim 4.32)
 	id 1CYtWN-00038Y-2h; Mon, 29 Nov 2004 16:57:23 -0500
X-test-idtracker: no
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
        RFC Editor <rfc-editor@rfc-editor.org>,
        v6ops mailing list <v6ops@ops.ietf.org>,
        v6ops chair <pekkas@netcore.fi>,
        v6ops chair <jonne.Soininen@nokia.com>
Subject: Document Action: 'Analysis on IPv6 Transition in 3GPP
          Networks' to Informational RFC
Message-Id: <E1CYtWN-00038Y-2h@megatron.ietf.org>
Date: Mon, 29 Nov 2004 16:57:23 -0500
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham
 	version=3.0.1
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

The IESG has approved the following document:

- 'Analysis on IPv6 Transition in 3GPP Networks '
    <draft-ietf-v6ops-3gpp-analysis-11.txt> as an Informational RFC

This document is the product of the IPv6 Operations Working Group.

The IESG contact persons are David Kessens and Bert Wijnen.

RFC Editor Note:

The editor of draft-ietf-v6ops-3gpp-analysis-08.txt requests that the text:

Replace the two last paragraphs (after Figure 1) in section 4.1 of
draft-ietf-v6ops-3gpp-analysis-11.txt with the following text:

-----------

On reception of an INVITE, the SIP server reserves an IP address and a
port from the TrGW both for IPv4 and IPv6. Then, the SIP server acts
as a B2BUA (Back-to-Back User Agent) and rewrites the SDP of the
INVITE to insert the transition gateway in the middle of the media
flow between the two end-points.

When performing its B2BUA role, the SIP server acts as a UA (User
Agent) towards both the IMS and the IPv4 host. Consequently, the SIP
server needs to support all the extensions that apply to the session,
which are listed in the Require header fields of the SIP messages.

This approach has a number of important drawbacks, however. The
biggest drawback is that the rewriting of the SDP in the SIP signaling
prevents securing the SDP payload between the two end-points.
Additionally, it breaks the end-to-end negotiation of SIP extensions
required for each session. Therefore, the extensions to be
used in a particular session are limited by the extensions supported
by the SIP server acting as a B2BUA. That is, the introduction of a
new extension requires upgrading not only the UAs, but the B2BUAs as
well.

This analysis clearly shows that a new solution for IPv4-IPv6
interworking in SIP networks is needed. The ability to convey multiple
alternative addresses in SDP session descriptions [SDP ANAT] represents
a step in this direction.

Given the problems related to the use of B2BUAs, it is recommended that
the SIP-related Working Groups quickly work on a solution to overcome
the drawbacks of this approach.

---------

Add to Informational references:

[SDP ANAT] Camarillo, G. and J. Rosenberg, "The Alternative Network
Address Types Semantics (ANAT) for the Session Description Protocol
(SDP) Grouping Framework", October 2004, draft-ietf-mmusic-anat-02.txt,
work in progress.

----------

Technical Summary

   This document analyzes the transition to IPv6 in Third Generation
Partnership Project (3GPP) General Packet Radio Service (GPRS) packet networks.
The focus is on analyzing different transition scenarios, applicable transition
mechanisms and finding solutions for those transition scenarios. In these
scenarios, the User Equipment (UE) connects to other nodes, e.g. in the
Internet, and IPv6/IPv4 transition mechanisms are needed.

Working Group Summary

   This document is the product of the IPv6 Operations Working Group

Protocol Quality

   This document was reviewed for the IESG by David Kessens.




From owner-v6ops@ops.ietf.org  Tue Nov 30 01:30:30 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28288
	for <v6ops-archive@lists.ietf.org>; Tue, 30 Nov 2004 01:30:29 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
	id 1CZ1VJ-0008ZN-FU
	for v6ops-data@psg.com; Tue, 30 Nov 2004 06:28:49 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.43 (FreeBSD))
	id 1CZ1VI-0008Z2-Ct
	for v6ops@ops.ietf.org; Tue, 30 Nov 2004 06:28:48 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id iAU6ShO28403;
	Tue, 30 Nov 2004 08:28:45 +0200
Date: Tue, 30 Nov 2004 08:28:43 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: Gert Doering <gert@Space.Net>
cc: v6ops@ops.ietf.org
Subject: Re: Take VLAN usage as WG document?
In-Reply-To: <20041129152144.GK84850@Space.Net>
Message-ID: <Pine.LNX.4.61.0411300823300.27105@netcore.fi>
References: <Pine.LNX.4.61.0411290816370.26365@netcore.fi>
 <20041129152144.GK84850@Space.Net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.0.1
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

On Mon, 29 Nov 2004, Gert Doering wrote:
> I think it would make a useful informational document.
>
> Personally, I find this approach "obvious" - but that's only because
> I've already been through the process of wondering how to bring IPv6 to
> our VLAN infrastructure (which was served by a VLAN router that was
> conveniently declared as "End of Life" just one OS release before
> the general introduction of IPv6), and ended up doing it exactly
> this way - the existing IPv4 router stays, a new box for IPv6 only
> VLAN routing is built (which is not as powerful as the IPv4 router, but
> sufficient for v6).

(without any hats, of course.)

I also think this makes a useful document.  As with Gert, we've used 
VLANs in the scenario where an upgrade of the v4 router was not an 
option (because s/w was not available, due to concerns about its 
stability and performance, etc.), and used both separate PC routers, 
and "real" routers to act as v6 routers for a LAN.

We've now phased those out, because we moved to full dual-stack, but 
the situation is likely to come up again for others, and it's worth 
documenting.

However, it's also worth documenting the concerns raised by Heikki 
Vatiainen wrt. the enterprise document that separate IP topologies in 
the same links are likely to cause maintenance nightmares in the long 
term.  We certainly had those concerns ourselves.

-- 
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 owner-v6ops@ops.ietf.org  Tue Nov 30 02:56:58 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18181
	for <v6ops-archive@lists.ietf.org>; Tue, 30 Nov 2004 02:56:57 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
	id 1CZ2qi-0007lt-0b
	for v6ops-data@psg.com; Tue, 30 Nov 2004 07:55:00 +0000
Received: from [195.30.1.100] (helo=moebius2.Space.Net)
	by psg.com with smtp (Exim 4.43 (FreeBSD))
	id 1CZ2qg-0007ky-Qx
	for v6ops@ops.ietf.org; Tue, 30 Nov 2004 07:54:59 +0000
Received: (qmail 88262 invoked by uid 1007); 30 Nov 2004 07:54:57 -0000
Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=testkey; d=space.net;
  b=o4BBbEFULWF0YkLjOGlBzQ9ACgXgjCstY+CR50T7p4LFSc9nVaQFtgj+hEqMkY5x  ;
Date: Tue, 30 Nov 2004 08:54:57 +0100
From: Gert Doering <gert@space.net>
To: Pekka Savola <pekkas@netcore.fi>
Cc: Gert Doering <gert@space.net>, v6ops@ops.ietf.org
Subject: Re: Take VLAN usage as WG document?
Message-ID: <20041130075457.GR84850@Space.Net>
References: <Pine.LNX.4.61.0411290816370.26365@netcore.fi> <20041129152144.GK84850@Space.Net> <Pine.LNX.4.61.0411300823300.27105@netcore.fi>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.61.0411300823300.27105@netcore.fi>
User-Agent: Mutt/1.4.1i
X-NCC-RegID: de.space
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham 
	version=3.0.1
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

Hi,

On Tue, Nov 30, 2004 at 08:28:43AM +0200, Pekka Savola wrote:
> However, it's also worth documenting the concerns raised by Heikki 
> Vatiainen wrt. the enterprise document that separate IP topologies in 
> the same links are likely to cause maintenance nightmares in the long 
> term.  We certainly had those concerns ourselves.

I agree.  It makes documentation and troubleshooting harder (now 
*which* router is that machine connected to?), and also brings up some 
security issues ("is the v6 ACL in sync with the v4 ACL?").

The security issues are mentioned already, though.

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  66629  (65398)

SpaceNet AG                 Mail: netmaster@Space.Net
Joseph-Dollinger-Bogen 14   Tel : +49-89-32356-0
80807 Muenchen              Fax : +49-89-32356-299




From owner-v6ops@ops.ietf.org  Tue Nov 30 06:53:17 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09199
	for <v6ops-archive@lists.ietf.org>; Tue, 30 Nov 2004 06:53:16 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
	id 1CZ6Wb-000Hbt-CS
	for v6ops-data@psg.com; Tue, 30 Nov 2004 11:50:29 +0000
Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk)
	by psg.com with esmtp (Exim 4.43 (FreeBSD))
	id 1CZ6Wa-000HbZ-GG
	for v6ops@ops.ietf.org; Tue, 30 Nov 2004 11:50:28 +0000
Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131])
	by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id iAUBoRi3007541
	for <v6ops@ops.ietf.org>; Tue, 30 Nov 2004 11:50:27 GMT
Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162])
	by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id LAA22650
	for <v6ops@ops.ietf.org>; Tue, 30 Nov 2004 11:50:24 GMT
Received: (from tjc@localhost)
	by login.ecs.soton.ac.uk (8.11.6/8.11.6) id iAUBoNH28714
	for v6ops@ops.ietf.org; Tue, 30 Nov 2004 11:50:23 GMT
Date: Tue, 30 Nov 2004 11:50:23 +0000
From: Tim Chown <tjc@ecs.soton.ac.uk>
To: v6ops@ops.ietf.org
Subject: Re: Take VLAN usage as WG document?
Message-ID: <20041130115023.GD28412@login.ecs.soton.ac.uk>
Mail-Followup-To: v6ops@ops.ietf.org
References: <Pine.LNX.4.61.0411290816370.26365@netcore.fi> <20041129152144.GK84850@Space.Net> <Pine.LNX.4.61.0411300823300.27105@netcore.fi> <20041130075457.GR84850@Space.Net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20041130075457.GR84850@Space.Net>
User-Agent: Mutt/1.4i
X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information
X-ECS-MailScanner: Found to be clean
X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham 
	version=3.0.1
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

On Tue, Nov 30, 2004 at 08:54:57AM +0100, Gert Doering wrote:
> Hi,
> 
> On Tue, Nov 30, 2004 at 08:28:43AM +0200, Pekka Savola wrote:
> > However, it's also worth documenting the concerns raised by Heikki 
> > Vatiainen wrt. the enterprise document that separate IP topologies in 
> > the same links are likely to cause maintenance nightmares in the long 
> > term.  We certainly had those concerns ourselves.
> 
> I agree.  It makes documentation and troubleshooting harder (now 
> *which* router is that machine connected to?), and also brings up some 
> security issues ("is the v6 ACL in sync with the v4 ACL?").
> 
> The security issues are mentioned already, though.

If the document is adopted, then we can certainly add a section on
limitations and operational issues with the approach, though those are
included to some extent in the text as is.

Tim



From owner-v6ops@ops.ietf.org  Tue Nov 30 18:50:01 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01464
	for <v6ops-archive@lists.ietf.org>; Tue, 30 Nov 2004 18:50:01 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
	id 1CZHik-000LOv-2x
	for v6ops-data@psg.com; Tue, 30 Nov 2004 23:47:46 +0000
Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com)
	by psg.com with esmtp (Exim 4.43 (FreeBSD))
	id 1CZHij-000LOh-4b
	for v6ops@ops.ietf.org; Tue, 30 Nov 2004 23:47:45 +0000
Received: from sj-core-4.cisco.com (171.68.223.138)
  by sj-iport-5.cisco.com with ESMTP; 30 Nov 2004 15:47:59 -0800
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
Received: from sasad-w2k01.cisco.com (sjc-vpn4-777.cisco.com [10.21.83.8])
	by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id iAUNlcA6024334;
	Tue, 30 Nov 2004 15:47:38 -0800 (PST)
Message-Id: <4.3.2.7.2.20041130154225.02ee6718@ce-nfs-1.cisco.com>
X-Sender: sasad@ce-nfs-1.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 30 Nov 2004 15:47:38 -0800
To: v6ops@ops.ietf.org
From: Salman Asadullah <sasad@cisco.com>
Subject: Need a suggestion ...
Cc: Ciprian Popoviciu <cpopovic@cisco.com>, adeel Ahmed <adahmed@cisco.com>,
        Patrick Grossetete <pgrosset@cisco.com>
In-Reply-To: <4.3.2.7.2.20041122131124.02aaa368@ce-nfs-1.cisco.com>
References: <4.3.2.7.2.20041119133905.023cd410@fruitpie.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.0.1
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

Hello All,

We would like to take a quick poll from the group regarding structure of 
our following draft, ISP IPv6 Deployment Scenarios in Broadband Access 
Networks:

http://www.ietf.org/internet-drafts/draft-asadullah-v6ops-bb-deployment-scenarios-01.txt

Currently this draft is ~ 60 pages long, we would like to know if we should 
keep it the way it is or split it into 4 different drafts (~15-20 pages 
each) based on technology (DSL, Cable, ETTH, Wireless).

We are hearing two opinions:

1.  We should keep it the way it is, its long but complete and acts as a 
"one stop shop".   Reader can choose the section of interest easily.

2.  We should split the draft, it would result in a smaller technology 
specific draft and eventually more hits.  If we split the draft, there 
could be two options of doing it.

Option 2A: Section 1,2,3,4,5 (these are general section and pretty much 
applies to every BB technology) will be replicated in all 4 drafts. So, we 
will have 4 drafts in total.

Option 2B: Section 1,2,3,4,5 is part of a "general draft" followed by one 
paragraph for each technology where we refer the reader to the new 
technology specific draft.  So, we will have 5 drafts in total (1 general + 
4 technology specific).

Please let us know your thoughts, which route we should take.

Thank you all.

Regards,
Salman




From owner-v6ops@ops.ietf.org  Tue Nov 30 20:21:18 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09715
	for <v6ops-archive@lists.ietf.org>; Tue, 30 Nov 2004 20:21:18 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
	id 1CZJ9g-0007N1-HE
	for v6ops-data@psg.com; Wed, 01 Dec 2004 01:19:40 +0000
Received: from [192.18.98.36] (helo=brmea-mail-4.sun.com)
	by psg.com with esmtp (Exim 4.43 (FreeBSD))
	id 1CZJ9U-0007M7-FF
	for v6ops@ops.ietf.org; Wed, 01 Dec 2004 01:19:28 +0000
Received: from esunmail ([129.147.156.34])
	by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id iB11JRun026162
	for <v6ops@ops.ietf.org>; Tue, 30 Nov 2004 18:19:28 -0700 (MST)
Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM
 (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004))
 with ESMTP id <0I800056EROFUV@edgemail1.Central.Sun.COM> for
 v6ops@ops.ietf.org; Tue, 30 Nov 2004 18:19:27 -0700 (MST)
Received: from [192.168.1.2] ([66.93.39.75])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004))
 with ESMTPSA id <0I80007F7ROEOP@mail.sun.net> for v6ops@ops.ietf.org; Tue,
 30 Nov 2004 18:19:27 -0700 (MST)
Date: Tue, 30 Nov 2004 17:19:25 -0800
From: Alain Durand <Alain.Durand@Sun.COM>
Subject: Re: Take VLAN usage as WG document?
In-reply-to: <Pine.LNX.4.61.0411290816370.26365@netcore.fi>
To: Pekka Savola <pekkas@netcore.fi>
Cc: v6ops@ops.ietf.org
Message-id: <0A2877DC-4337-11D9-95F8-00039376A6AA@sun.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.619)
Content-type: text/plain; charset=US-ASCII; format=flowed
Content-transfer-encoding: 7BIT
References: <Pine.LNX.4.61.0411290816370.26365@netcore.fi>
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham 
	version=3.0.1
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7BIT


On Nov 28, 2004, at 10:22 PM, Pekka Savola wrote:

> Hi,
>
> (co-chair hat on)
>
> The author has asked if the document describing usage of VLANs for 
> IPv6 deployed could be taken as a WG document:
>
> http://www.ietf.org/internet-drafts/draft-chown-v6ops-vlan-usage-02.txt

YES.

IMHO, this is exactly the kind of document this wg should produce

	- Alain.