Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call

<> Fri, 30 January 2015 08:04 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id BA1371A89AE for <>; Fri, 30 Jan 2015 00:04:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0BNu6UDOXZSQ for <>; Fri, 30 Jan 2015 00:04:58 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B794E1A899A for <>; Fri, 30 Jan 2015 00:04:57 -0800 (PST)
Received: from (unknown [xx.xx.xx.198]) by (ESMTP service) with ESMTP id 4EC8A3744CD; Fri, 30 Jan 2015 09:04:56 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown []) by (ESMTP service) with ESMTP id 61D0C1800A0; Fri, 30 Jan 2015 09:04:54 +0100 (CET)
Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([]) by OPEXCLILH02.corporate.adroot.infra.ftgroup ([]) with mapi id 14.03.0224.002; Fri, 30 Jan 2015 09:04:54 +0100
From: <>
To: Ole Troan <>, "Fred Baker (fred)" <>
Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call
Thread-Index: AQHQOxuJv5W9vu3skUKiVKZnDa9kKZzW83IAgAFVDgA=
Date: Fri, 30 Jan 2015 08:04:53 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933004902552@OPEXCLILM23.corporate.adroot.infra.ftgroup>
References: <> <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version:, Antispam-Engine:, Antispam-Data: 2014.12.16.134821
Archived-At: <>
Cc: "" <>, V6 Ops List <>
Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 30 Jan 2015 08:05:00 -0000

Hi Ole,

Thank you for the comments.

Please see inline.


-----Message d'origine-----
De : Ole Troan [] 
Envoyé : jeudi 29 janvier 2015 13:15
À : Fred Baker (fred)
Cc : V6 Ops List;
Objet : Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call

> On 28 Jan 2015, at 17:57 , Fred Baker (fred) <> wrote:
> draft-ietf-v6ops-mobile-device-profile has been through Quite a bit of change in the IESG. The ADs would like to see the working group read it again and comment - working group last call - before they proceed. To summarize, it provides requirements for handsets that would work in a specific business model. As such, it builds on RFC 6434 and 7066, strengthening some of those requirements, and going on to add requirements related to 464xlat and other technologies.
> Please read it now, and comment. This WGLC will run until 15 February.

+1 to Lorenzo's comments.

in addition.

   C_REC#11:  If the cellular host receives the DNS information in
              several channels for the same interface, the following
              preference order must be followed:

                 1.  PCO

                 2.  RA

                 3.  DHCPv6

in the other areas this issue has come up. then the conclusion has been that the host uses all the information received. I think it would be quite unfortunate that the host stack much behave differently depending on the link-layer. I would suggest either to drop the requirement, or to say that the implementation must use all DNS servers learnt.

[Med] FWIW, this was added to have a more deterministic behavior at the cellular side. I may lost the context since early stages of the draft, but I recall there was a discussion in the list asking to make the ordering more strict: see for instance: Using all the information or follow the selection modes are two ways to achieve the same objective: determinist behavior at the terminal side. The draft recorded the feedback we received at that time.

same comment applies to W_REC#4.
[Med] There is no W_REC# in the current version. I think you are referring to W_REC#2. Same as above.

I can't see a good reason why hosts that also have cellular interfaces should work differently on a WLAN as opposed to those that don't have cellular interfaces.
[Med] The main motivation for this section was the test we have conducted on some IPv6-enabled devices that do not behave correctly when IPv6-only mode (you can see for instance what we reported here: This is an example of implementation brokenness to be avoided.

why does e.g. A_REC#3 refer to NATs?
[Med] A_REC#3 is when IPv4 service continuity is provided over IPv6. 

"Tracking a host is still possible based on the first 64
 bits of the IPv6 address.  Means to prevent against such
 tracking issues may be enabled in the network side."

what does this allude to?
[Med] All what it says is that if a host doesn't want to be tracked, changing the last 64 bits may not be sufficient.