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

Ole Troan <> Thu, 29 January 2015 12:15 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 75B7A1A0318 for <>; Thu, 29 Jan 2015 04:15:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jsPggWOSPeOo for <>; Thu, 29 Jan 2015 04:15:09 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 06A271A0275 for <>; Thu, 29 Jan 2015 04:15:09 -0800 (PST)
Received: from (localhost []) by (Postfix) with ESMTP id 7E2F961E9; Thu, 29 Jan 2015 04:15:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s= selector1; bh=Beezg9YNROxgNOdGAVNEbUrDXAA=; b=pGvn+nJ7UBkdoZ4Ce9 cyZ3p4WpN9tr6hKBHOgjbEzASRLWgx6sDCe0tgEjMQ5kXnGg9YMT2XpvUp31bjjt Zel0i38CziVa8Wabf67y9k0pkqVGjQdpRhbfQiDznDP+p6JYpOz6BihYm9LBKqex Lyt5Rii53AEhaBuldkdB3QGho=
DomainKey-Signature: a=rsa-sha1; c=nofws;; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; q=dns; s= selector1; b=dyTLHJZysdgDqtmnFzNdgaw/cx3Rf2jA/NrI5XhZdMmyFlCJxnm GcJ9CqwlWYVtZU4wXFHi8RT95DZamDbW1EP7ht3gsW4CSRpp8jguzE9iPxFvGlNQ GbeM6p4NSv2MXrEefJpLsA9aWinSXoct1wpQ0eJ8P1imAZRyi0ERTVEU=
Received: from OTROAN-M-Q0RH.localdomain ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by (Postfix) with ESMTPSA id 27CB461C5; Thu, 29 Jan 2015 04:15:07 -0800 (PST)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by OTROAN-M-Q0RH.localdomain (Postfix) with ESMTP id DD3793D85726; Thu, 29 Jan 2015 13:15:04 +0100 (CET)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.4\))
From: Ole Troan <>
In-Reply-To: <>
Date: Thu, 29 Jan 2015 13:15:04 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: "Fred Baker (fred)" <>
X-Mailer: Apple Mail (2.2070.4)
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: Thu, 29 Jan 2015 12:15:10 -0000

> 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.

same comment applies to W_REC#4.
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.

why does e.g. A_REC#3 refer to NATs?

"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?