IETF Logo Mail Archive

RE: draft-ietf-v6ops-cpe-simple-security-04 WGLC

<teemu.savolainen@nokia.com> Fri, 24 April 2009 11:47 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 E9A1B3A6AB7 for <ietfarch-v6ops-archive@core3.amsl.com>; Fri, 24 Apr 2009 04:47:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.74
X-Spam-Level:
X-Spam-Status: No, score=-4.74 tagged_above=-999 required=5 tests=[AWL=-0.845, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_43=0.6, 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 Of0D8Gu1EYP3 for <ietfarch-v6ops-archive@core3.amsl.com>; Fri, 24 Apr 2009 04:47:44 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8EB6C3A6A05 for <v6ops-archive@lists.ietf.org>; Fri, 24 Apr 2009 04:47:44 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-v6ops@ops.ietf.org>) id 1LxJs3-000Avp-QU for v6ops-data0@psg.com; Fri, 24 Apr 2009 11:47:07 +0000
Received: from [192.100.122.230] (helo=mgw-mx03.nokia.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from <teemu.savolainen@nokia.com>) id 1LxJrq-000Atp-L9 for v6ops@ops.ietf.org; Fri, 24 Apr 2009 11:47:00 +0000
Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n3OBkM7A000794; Fri, 24 Apr 2009 14:46:41 +0300
Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 24 Apr 2009 14:46:15 +0300
Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 24 Apr 2009 14:46:10 +0300
Received: from nok-am1mhub-07.mgdnok.nokia.com (65.54.30.14) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.1.340.0; Fri, 24 Apr 2009 13:46:09 +0200
Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-07.mgdnok.nokia.com ([65.54.30.14]) with mapi; Fri, 24 Apr 2009 13:46:09 +0200
From: teemu.savolainen@nokia.com
To: fred@cisco.com, v6ops@ops.ietf.org
CC: kurtis@kurtis.pp.se, rbonica@juniper.net, Basavaraj.Patil@nokia.com, jouni.korhonen@nsn.com
Date: Fri, 24 Apr 2009 13:45:30 +0200
Subject: RE: draft-ietf-v6ops-cpe-simple-security-04 WGLC
Thread-Topic: draft-ietf-v6ops-cpe-simple-security-04 WGLC
Thread-Index: Acm94LDbhPGzIm4HRiWyaNi4/b1q9wG67Osg
Message-ID: <18034D4D7FE9AE48BF19AB1B0EF2729F27F2C05DC3@NOK-EUMSG-01.mgdnok.nokia.com>
References: <32129337-7BED-4D7A-AF06-BC5ABB37D994@cisco.com>
In-Reply-To: <32129337-7BED-4D7A-AF06-BC5ABB37D994@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 24 Apr 2009 11:46:10.0625 (UTC) FILETIME=[43314B10:01C9C4D2]
X-Nokia-AV: Clean
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

Hi,

I believe this document is of operational utility. 

Few comments/questions:
- 3.2.2. describes, as per RFC4787, that UDP mappings MUST NOT expire in less than two minutes. As I don't know the backgrounds of this decision, I wonder why the minimum time could not be longer for IPv6? The longer the time the less need to activate radio for keep-alive sending (on either side of the firewall btw - consider a case where CPE has wireless WAN). In CGN case short timeout is understandable due need to save public ports, but that probably is not an issue in simple IPv6 firewall. So why e.g. not two hours as for TCP?
- 3.2.5. Just to check that DSMIP6 is considered as one of these other tunneling protocols mentioned in R22? How about MIP6 route optimization, will that work through a device implementing this specification?
- 3.4 says it remains to be seen if UPnP:IGD is to be extended for IPv6. I would rather say that IPv6 is being added to UPnP:IDG2. See: "http://www.upnp.org/resources/documents/UPnPIGD2vsIGD1d10032009.pdf  "UPnP Gateway committee: IGD:2 improvements over IGD:1"

Best regards,

	Teemu


>-----Original Message-----
>From: owner-v6ops@ops.ietf.org 
>[mailto:owner-v6ops@ops.ietf.org] On Behalf Of ext Fred Baker
>Sent: 15 April, 2009 18:27
>To: IPv6 Operations
>Cc: kurtis@kurtis.pp.se; rbonica@juniper.net
>Subject: draft-ietf-v6ops-cpe-simple-security-04 WGLC
>
>This is to initiate a two week working group last call of 
>draft-ietf- v6ops-cpe-simple-security-04. Please read it now. 
>If you find nits (spelling errors, minor suggested wording 
>changes, etc), comment to the authors; if you find greater 
>issues, such as disagreeing with a statement or finding 
>additional issues that need to be addressed, please post your 
>comments to the list.
>
>We are looking specifically for comments on the importance of 
>the document as well as its content. If you have read the 
>document and believe it to be of operational utility, that is 
>also an important comment to make.
>
>

v2.23.0 | Report a Bug | By Email