Re: Proposed agenda for IPv6 Operations - IETF 77

Rémi Després <remi.despres@free.fr> Sun, 21 March 2010 18:04 UTC

Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07EDD3A685A for <ietfarch-v6ops-archive@core3.amsl.com>; Sun, 21 Mar 2010 11:04:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.332
X-Spam-Level: *
X-Spam-Status: No, score=1.332 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id akaRXza-Vq-B for <ietfarch-v6ops-archive@core3.amsl.com>; Sun, 21 Mar 2010 11:04:33 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 878573A682E for <v6ops-archive@lists.ietf.org>; Sun, 21 Mar 2010 11:04:33 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from <owner-v6ops@ops.ietf.org>) id 1NtPUA-000HcH-Ns for v6ops-data0@psg.com; Sun, 21 Mar 2010 18:02:50 +0000
Received: from [93.17.128.19] (helo=smtp23.services.sfr.fr) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <remi.despres@free.fr>) id 1NtPU7-000Hc1-GE for v6ops@ops.ietf.org; Sun, 21 Mar 2010 18:02:47 +0000
Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2304.sfr.fr (SMTP Server) with ESMTP id CF9867000091; Sun, 21 Mar 2010 19:02:45 +0100 (CET)
Received: from [130.129.24.236] (unknown [130.129.24.236]) by msfrf2304.sfr.fr (SMTP Server) with ESMTP id 8610670000B1; Sun, 21 Mar 2010 19:02:43 +0100 (CET)
X-SFR-UUID: 20100321180243549.8610670000B1@msfrf2304.sfr.fr
Subject: Re: Proposed agenda for IPv6 Operations - IETF 77
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset="iso-8859-1"
From: Rémi Després <remi.despres@free.fr>
In-Reply-To: <E1829B60731D1740BB7A0626B4FAF0A64951224DAC@XCH-NW-01V.nw.nos.boeing.com>
Date: Sun, 21 Mar 2010 11:02:42 -0700
Cc: Fred Baker <fred@cisco.com>, IPv6 Operations <v6ops@ops.ietf.org>, Ron Bonica <ron@bonica.org>, Kurt Erik Lindqvist <kurtis@kurtis.pp.se>
Content-Transfer-Encoding: quoted-printable
Message-Id: <EB83AD40-72D3-4B64-B768-B23A970CD865@free.fr>
References: <2A0BDC9E-9C5A-4D75-83E6-C7D058264CAC@cisco.com> <E1829B60731D1740BB7A0626B4FAF0A64951224D7B@XCH-NW-01V.nw.nos.boeing.com> <2AB0B1CD-6E10-4EA5-9793-FA4039828993@cisco.com> <E1829B60731D1740BB7A0626B4FAF0A64951224DAC@XCH-NW-01V.nw.nos.boeing.com>
To: "Templin, Fred L" <Fred.L.Templin@boeing.com>
X-Mailer: Apple Mail (2.1077)
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

Fred,

On February 19, I wrote on to Fred, with copy to the v6ops list:
<<<
Draft-despres-softwire-sam-00, which I will post in a few days, contains an updated description of SAM, the generic Stateless Address Mapping mechanism which applies to a variety of scenarios.

Among those, one permits ISPs to deliver native IPv6 connectivity across legacy CPEs that only support NAT44 with port forwarding.
This solution is like 6rd in that:
- ISPs don't need to change their IPv4 infrastructures
- They only need to operate gateways between these and their IPv6 accesses
- These gateways are stateless
It is unlike 6rd in that:
- Legacy CPEs don't need to be upgraded
- To exploit of their IPv6 addresses, hosts have to be upgraded to support SAM.

Operation considerations of this scenario are relevant to v6ops.
A time slot for a presentation will be appreciated.
>>>

Although the agenda of v6ops doesn't specify it, what I will present on friday is very far from a general SAM presentation like the one I asked to have in Softwire, but couldn't be scheduled due to the lack of enough time allocated to Softwire.

As initially planned, my presentation will be limited to the "Native IPv6 across NAT44s" scenario.

Regards,
RD



Le 21 mars 2010 à 07:02, Templin, Fred L a écrit :

> Fred,
> 
> As far as I can tell, the SAM proposal is a new transitional
> technology and protocol also. RANGER and SAM are addressing
> very similar problem spaces, and I think their eligibility
> for inclusion in the v6ops agenda should be considered on
> equal terms.
> 
> Thanks - Fred
> fred.l.templin@boeing.com
> 
>> -----Original Message-----
>> From: Fred Baker [mailto:fred@cisco.com]
>> Sent: Saturday, March 20, 2010 10:28 PM
>> To: Templin, Fred L
>> Cc: IPv6 Operations; Ron Bonica; Kurt Erik Lindqvist
>> Subject: Re: Proposed agenda for IPv6 Operations - IETF 77
>> 
>> I have a question on these.
>> 
>> Per the abstract of VET, "VET can also be considered as version 2 of the Intra-Site Automatic Tunnel
>> Addressing Protocol (i.e., "ISATAPv2")." I tend to agree; with routing, next hop determination, and a
>> "Subnetwork Encapsulation and Adaptation Layer (SEAL)", I don't think this is an operational
>> description. I think this belongs discussed in rrg, rtgarea/rtgwg, or *maybe* int-area.
>> 
>> How about you and I discuss this Monday and you convince me that this is within the charter of IPv6
>> Operations. I think it is that which was explicitly placed outside the charter - transitional
>> technologies and protocol development.
>> 
>> 
>> On Mar 20, 2010, at 2:31 AM, Templin, Fred L wrote:
>> 
>>> Fred,
>>> 
>>> The new agenda posted on the webpages does not seem to match the one
>>> you posted to the list:
>>> 
>>>  http://www.ietf.org/proceedings/10mar/agenda/v6ops.html
>>> 
>>> Seeing that there are new additions, I would like to propose to add the
>>> RANGER, VET and SEAL trilogy - preferably as the final session on
>>> Friday, as I have two other conflicts for the earlier portion of that session.
>>> The talk would require 15min, and would cover all three documents
>>> together (i.e., not as three separate talks). The documents are here:
>>> 
>>>  http://www.ietf.org/rfc/rfc5720.txt
>>>  http://tools.ietf.org/html/draft-templin-intarea-vet
>>>  http://tools.ietf.org/html/draft-templin-intarea-seal
>>> 
>>> Thanks - Fred
>>> fred.l.templin@boeing.com
>>> 
>>> From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Fred Baker
>>> Sent: Tuesday, March 16, 2010 2:06 PM
>>> To: IPv6 Operations
>>> Subject: Proposed agenda for IPv6 Operations - IETF 77
>>> 
>>> Comments please... Basically I am putting three security issues and two 3GPP-relevant drafts on
>> Monday morning and the remainder on Friday morning. Each discussion gets about half an hour. If time
>> permits in the meeting, I'll pull agenda items forward from Friday to Monday. I have two drafts on
>> here that were not marked for v6ops but the authors asked me to include; next time I'd appreciate it
>> if folks used the draft-*-v6ops-* naming convention; it makes my job easier. If I have missed
>> anything, let me know.
>>> IPv6 Operations - IETF 77
>>> 
>>> Monday 22 March, 9:00 AM
>>> 
>>> Agenda bashing
>>> 
>>> Recommended Simple Security Capabilities in Customer Premises Equipment for Providing Residential
>> IPv6 Internet Service
>>> 18-Feb-10, <draft-ietf-v6ops-cpe-simple-security-09.txt>
>>> Advanced Security for IPv6 CPE
>>> 8-Mar-10, <draft-vyncke-advanced-ipv6-security-01.txt>
>>> Routing Loops using ISATAP and 6to4: Problem Statement and Proposed Solutions
>>> 1-Feb-10, <draft-nakibly-v6ops-tunnel-loops-01.txt>
>>> 
>>> IPv6 in 3GPP Evolved Packet System
>>> 24-Feb-10, <draft-korhonen-v6ops-3gpp-eps-01.txt>
>>> Mobile Networks Considerations for IPv6 Deployment
>>> 8-Mar-10, <draft-koodli-ipv6-in-mobile-networks-01.txt>
>>> Friday 26 March, 9:00 AM
>>> 
>>> Emerging Service Provider Scenarios for IPv6 Deployment
>>> 23-Feb-10, <draft-carpenter-v6ops-isp-scenarios-01.txt>
>>> Unicast Transmission of IPv6 Multicast Messages on Link-layer
>>> 15-Feb-10, <draft-gundavelli-v6ops-l2-unicast-00.txt>
>>> Neighbor Cache Protection in Neighbor Discovery Protocol
>>> 2-Mar-10, <draft-jiang-v6ops-nc-protection-01.txt>
>>> DHCPv6 Prefix Delegation as IPv6 Migration Tool in Cellular Networks
>>> 16-Feb-10, <draft-sarikaya-v6ops-prefix-delegation-00.txt>
>>> Advanced Requirements for IPv6 Customer Edge Routers
>>> 8-Mar-10, <draft-wbeebee-v6ops-ipv6-cpe-router-bis-02.txt>
>>> 
>>> 
>>> http://www.ipinc.net/IPv4.GIF
>>> 
>> 
>> http://www.ipinc.net/IPv4.GIF
> 
>