IETF Logo Mail Archive

Re: [v6ops] draft-ietf-v6ops-64share

Lorenzo Colitti <lorenzo@google.com> Tue, 30 July 2013 15:51 UTC

Return-Path: <lorenzo@google.com>
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 52ECD11E8103 for <v6ops@ietfa.amsl.com>; Tue, 30 Jul 2013 08:51:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Fo97oswf23d for <v6ops@ietfa.amsl.com>; Tue, 30 Jul 2013 08:50:59 -0700 (PDT)
Received: from mail-oa0-x22f.google.com (mail-oa0-x22f.google.com [IPv6:2607:f8b0:4003:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 9FAC011E80D7 for <v6ops@ietf.org>; Tue, 30 Jul 2013 08:50:59 -0700 (PDT)
Received: by mail-oa0-f47.google.com with SMTP id m6so9536297oag.20 for <v6ops@ietf.org>; Tue, 30 Jul 2013 08:50:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=T7x8xjTd+0kUzuJZpAIfLkBZ0bFNJwe7K3VB88i5OCc=; b=Hv7CJyFBjxHdrmRABLAYJoJHgU6cTIQtF5CoCZz/rbWjt28jh0zCjmkUSIfGfgkmos 4WRcxwgL7A/tEzeRXPj2WLmQe+HbEY0RBdWqCly3GZ7idLujzOAS9SnZwt9bHqbhnVfT O/tSpKgoy8/yMM1U5V5hWEnNSw+8X9e1vBHe8xHdWGsTqVL1WcJAAjsNUrdidrCPx99c MNpAOB8BL4kgp9gkgw1TuDgcVmrr8MYH8hrv1C+eySnobUzooN0Czq+PfRYzcFafW5Oz 9mnhTaWcv/8l9ejEY2pmcKLOaGumk2TzsgM3HJw7RR67H6scK9F0qY0tJbnJBQYo3FU2 EWgQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=T7x8xjTd+0kUzuJZpAIfLkBZ0bFNJwe7K3VB88i5OCc=; b=Vn73NblsKKKH1b62IeLijpb/ZlYvClXivdKeGGNV7nnCBCxWyh/hfLyWONzI0k+yvA Jin1M03R9kAWy6VtP0eXMeBaRMoZjyIXL4UzEWHvZnLmAhyfiMQLaSxTRBj84pjCCw1P MmYIxKEQOrQDk+JLqgcRwae0dF2EqVwptMOoprqoqdQ6P5Ck+WMacvDvU9aV1/R1BCU8 VLOVDQWWTaE3ZqCVeqKPfQcYBRkpOF/qgLnFzx84qoP6yukuEsDSU5HEIZ90Q0K27ynH RdMeD17AtNatxmQ31eNqB+PUPj3pJVrfXSm1+3i+B5b5MxbHv7pFaGKBApMxHaFm+zt3 uHkg==
X-Received: by 10.50.18.5 with SMTP id s5mr241348igd.6.1375199459088; Tue, 30 Jul 2013 08:50:59 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.228.144 with HTTP; Tue, 30 Jul 2013 08:50:38 -0700 (PDT)
In-Reply-To: <CAD6AjGRq=oXdQ51Nme5VJ5V4-G6c6KHqHOnNpfW9PyfydJvPHQ@mail.gmail.com>
References: <12351.1375184644@sandelman.ca> <CAD6AjGSG7B=7sGtj0Xjxyh2g5MnMxiopuEUeqJ6LgD=G=zS=-g@mail.gmail.com> <8966.1375196027@sandelman.ca> <CAD6AjGRq=oXdQ51Nme5VJ5V4-G6c6KHqHOnNpfW9PyfydJvPHQ@mail.gmail.com>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Tue, 30 Jul 2013 17:50:38 +0200
Message-ID: <CAKD1Yr33CD=Vw_sji2wUTW4_OCakyxdiuKrc4VmqmOUqnyZHXA@mail.gmail.com>
To: "cb.list6" <cb.list6@gmail.com>
Content-Type: multipart/alternative; boundary="089e013cc1c44145f104e2bc93d3"
X-Gm-Message-State: ALoCoQm0zRzW1SxN4xq8AFERCixKojrU0C1T+MFuvUcFuwiL3ySlyZjWZyiRmfqKIcDwk5lrdgroYhqynmdSCyJ+6hKOEBXCsWT4pLOZpBQWZg58IMQOHHcWJnlDTBjJ1hhFeXd3fGuq8HogmV7y2CnIEcMPVBgMBShOBShnG1Y3bx3PuNBmDNo1kWEUrxphBzEkKvoIkSnA
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, IPv6 Ops WG <v6ops@ietf.org>
Subject: Re: [v6ops] draft-ietf-v6ops-64share
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: Tue, 30 Jul 2013 15:51:00 -0000

On Tue, Jul 30, 2013 at 5:03 PM, cb.list6 <cb.list6@gmail.com> wrote:

> It should not, i agree.  So, i am a little confused by your question.
>
> Scenario 1 moves the prefix from WAN to LAN, this may break an open
> connection.
>
> Scenario 2 replicates the IP on 2 interfaces
>

Why do we document these two as completely separate "scenarios"? As far as
I can see these "scenarios" are simply two ways of meeting the same
requirement, which is "the phone must not allow a tethered client to use an
IP address that is being used by the phone". Instead of having most of the
content of the document duplicated into two mostly-identical scenarios, can
we just list that requirement and provide two example ways of doing it?

(Neither of the two is correct, BTW - the right thing to do is for the
phone to keep all the addresses assigned to the northbound interface and
defend all of them against DAD on the southbound interfaces.)

v2.23.0 | Report a Bug | By Email