RE: Proposed agenda for IPv6 Operations - IETF 77

"Templin, Fred L" <Fred.L.Templin@boeing.com> Mon, 22 March 2010 14:33 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 33D9B3A688F for <ietfarch-v6ops-archive@core3.amsl.com>; Mon, 22 Mar 2010 07:33:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.23
X-Spam-Level:
X-Spam-Status: No, score=-4.23 tagged_above=-999 required=5 tests=[AWL=-1.765, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, 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 TOEFv+2pOu59 for <ietfarch-v6ops-archive@core3.amsl.com>; Mon, 22 Mar 2010 07:33:04 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8EC413A6802 for <v6ops-archive@lists.ietf.org>; Mon, 22 Mar 2010 07:32:53 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from <owner-v6ops@ops.ietf.org>) id 1NtieC-000OWM-OE for v6ops-data0@psg.com; Mon, 22 Mar 2010 14:30:28 +0000
Received: from [130.76.64.48] (helo=slb-smtpout-01.boeing.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from <Fred.L.Templin@boeing.com>) id 1Ntie8-000OVz-NI for v6ops@ops.ietf.org; Mon, 22 Mar 2010 14:30:25 +0000
Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o2MESDe0028772 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 22 Mar 2010 07:28:14 -0700 (PDT)
Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o2MESDk7010509; Mon, 22 Mar 2010 07:28:13 -0700 (PDT)
Received: from XCH-NWHT-07.nw.nos.boeing.com (xch-nwht-07.nw.nos.boeing.com [130.247.25.111]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o2MESDlD010498 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 22 Mar 2010 07:28:13 -0700 (PDT)
Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-07.nw.nos.boeing.com ([130.247.25.111]) with mapi; Mon, 22 Mar 2010 07:28:13 -0700
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: Rémi Després <remi.despres@free.fr>
CC: Fred Baker <fred@cisco.com>, IPv6 Operations <v6ops@ops.ietf.org>, Ron Bonica <ron@bonica.org>, Kurt Erik Lindqvist <kurtis@kurtis.pp.se>
Date: Mon, 22 Mar 2010 07:28:11 -0700
Subject: RE: Proposed agenda for IPv6 Operations - IETF 77
Thread-Topic: Proposed agenda for IPv6 Operations - IETF 77
Thread-Index: AcrJILf8Sd4DmktiSnCr5+LNEp6oqQAqoSYg
Message-ID: <E1829B60731D1740BB7A0626B4FAF0A64951224E31@XCH-NW-01V.nw.nos.boeing.com>
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> <EB83AD40-72D3-4B64-B768-B23A970CD865@free.fr>
In-Reply-To: <EB83AD40-72D3-4B64-B768-B23A970CD865@free.fr>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

Remi,

>From what I could tell, even for the NAT44 case you are
describing there is still a need for host modifications.
Also a need for DHCP server modifications, and a new
type of router in provider networks. That makes SAM a
new transition technology and a new protocol.

Fred
fred.l.templin@boeing.com

> -----Original Message-----
> From: Rémi Després [mailto:remi.despres@free.fr]
> Sent: Sunday, March 21, 2010 11:03 AM
> To: Templin, Fred L
> Cc: Fred Baker; IPv6 Operations; Ron Bonica; Kurt Erik Lindqvist
> Subject: Re: Proposed agenda for IPv6 Operations - IETF 77
> 
> 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
> >
> >
>