Re: [v6ops] draft-binet-v6ops-cellular-host-requirements-00.txt

Mikael Abrahamsson <swmike@swm.pp.se> Mon, 12 November 2012 08:12 UTC

Return-Path: <swmike@swm.pp.se>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4917E21F8487 for <v6ops@ietfa.amsl.com>; Mon, 12 Nov 2012 00:12:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.273
X-Spam-Level:
X-Spam-Status: No, score=-2.273 tagged_above=-999 required=5 tests=[AWL=-0.274, BAYES_00=-2.599, J_CHICKENPOX_41=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p1YRCo3hVSCh for <v6ops@ietfa.amsl.com>; Mon, 12 Nov 2012 00:12:57 -0800 (PST)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 5327C21F847D for <v6ops@ietf.org>; Mon, 12 Nov 2012 00:12:56 -0800 (PST)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 83D5E9C; Mon, 12 Nov 2012 09:12:53 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 7D5F89A; Mon, 12 Nov 2012 09:12:53 +0100 (CET)
Date: Mon, 12 Nov 2012 09:12:53 +0100 (CET)
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: mohamed.boucadair@orange.com
In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E947B1328@PUEXCB1B.nanterre.francetelecom.fr>
Message-ID: <alpine.DEB.2.00.1211120839240.27834@uplift.swm.pp.se>
References: <94C682931C08B048B7A8645303FDC9F36E947B1328@PUEXCB1B.nanterre.francetelecom.fr>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: IPv6 Ops WG <v6ops@ietf.org>
Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-requirements-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Nov 2012 08:12:58 -0000

On Mon, 12 Nov 2012, mohamed.boucadair@orange.com wrote:

> We hope this new version is ready for the WG adoption.

I support adopting this as WG item, but I have some questions:

In 
"http://www.etsi.org/deliver/etsi_ts/123400_123499/123401/09.13.00_60/ts_123401v091300p.pdf" 
it says:

"A UE which is IPv6 and IPv4 capable shall request for PDN type IPv4v6"

"If the requested PDN type is IPv4v6 and subscription data only allows PDN 
type IPv4 or only allows PDN type IPv6, the MME sets the PDN type 
according to the subscribed value. A reason cause shall be returned to the 
UE indicating that only the assigned PDN type is allowed. In this case the 
UE shall not request another PDN connection to the same APN for the other 
IP version"

So this draft is duplicating language from 3GPP spec:s, correct? What is 
the rationale for the "particular" in REQ#3? Either it's in compliance or 
it's not, right? Perhaps a short paragraph on why the behaviour listed is 
especially important?

Oh, REQ5 is interesting, I never understood how traffic was mapped into 
different bearers since the QoS is done per bearer. Now I know!

REQ#8: Should perhaps say GGSN/PGW intead of "GGSN" to comply with 3GPP 
language for LTE as well? (I don't understand why they changed the names, 
but they did so...)

REQ#9: Hm, I am not so sure about this one. What happens if PCO and 
RFC6106 gives different information? If DHCPv6 gives a third set? Or is 
this specified somewhere else?
... Ah, that's in REQ#10. my bad!

REQ#10: Why shouldn't the host support DHCPv6 recursive DNS retreival if 
RFC6106 is supported? DHCPv6 gives more information than RFC6106, I think 
the device should support DHCPv6 regardless of RFC6106 support.

REQ#11+12+13: +1 on the CLAT+NAT64+DNS64 stuff!

REQ#15: Is the rationale here that a device with IPv4v6 PDP context will 
get a DNS64 enabled resolver?

REQ#16: It would help here to just include the text "Happy Eyeballs" 
somewhere in the sentence, so I don't have to look at the RFC to identify 
what it is.

REQ#17: Should not do DAD on the PDP context interface. In case of 
tethering/hotspot, it needs to do DAD on the wifi/lan interface, right?

REQ#19: Shouldn't this be "IPv6 only"? A lot of devices today support 
IPv4+IPv6 on wifi, but they do not consider IPv6 only as "connected". 
Perhaps this could be clarified?

4. "these cellular devices have to meet". What does "have to" mean, is 
that a MUST but not written as such?


This looks like an extremely useful document to have when sendning out 
requirements to equipment vendors. Thanks!

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se