IETF Logo Mail Archive

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

"cb.list6" <cb.list6@gmail.com> Tue, 30 July 2013 15:03 UTC

Return-Path: <cb.list6@gmail.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 BDCA611E8214 for <v6ops@ietfa.amsl.com>; Tue, 30 Jul 2013 08:03:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.3
X-Spam-Level:
X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, 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 WRyE5VIe1xhG for <v6ops@ietfa.amsl.com>; Tue, 30 Jul 2013 08:03:41 -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 9619A11E81E1 for <v6ops@ietf.org>; Tue, 30 Jul 2013 08:03:41 -0700 (PDT)
Received: by mail-oa0-f47.google.com with SMTP id m6so9597298oag.34 for <v6ops@ietf.org>; Tue, 30 Jul 2013 08:03:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qa1cvkTiB515wBxHIAL20AJ7/h38UL1CgZAqVzamL88=; b=e1Tr0lJWfl+gWIh+6+x3lfv10qVnlwjRIw2yOQtDgqL8nKQitXs879VoApxdu1ShbF E8VfDiCErRNMoLCk+NxTQMOItNj9m4O13T4LmMSeLpmE9xuCWTVKg7vf3tt47qXQNFBC lQn8byvxmDl+LW3eMHrq9SAOcAnGqzPzwub4nXgJyyTXjdiHUrSby8PBsCKkibpyAgHL Avkr9hXY0nRa6bGZnzTkoCYqG0Pq6t98AKQo5BcLUq817Tw2cItlNUz9vETOEXvD5Ukr gOg0ID04J+AApzX5IqFfwpR8h4UUsUAqici4jkQjYr7X4jho4czQViltV+VA6aYNpKwt H/9A==
MIME-Version: 1.0
X-Received: by 10.50.127.167 with SMTP id nh7mr200279igb.34.1375196620238; Tue, 30 Jul 2013 08:03:40 -0700 (PDT)
Received: by 10.64.147.102 with HTTP; Tue, 30 Jul 2013 08:03:40 -0700 (PDT)
In-Reply-To: <8966.1375196027@sandelman.ca>
References: <12351.1375184644@sandelman.ca> <CAD6AjGSG7B=7sGtj0Xjxyh2g5MnMxiopuEUeqJ6LgD=G=zS=-g@mail.gmail.com> <8966.1375196027@sandelman.ca>
Date: Tue, 30 Jul 2013 08:03:40 -0700
Message-ID: <CAD6AjGRq=oXdQ51Nme5VJ5V4-G6c6KHqHOnNpfW9PyfydJvPHQ@mail.gmail.com>
From: "cb.list6" <cb.list6@gmail.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: 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:03:44 -0000

On Tue, Jul 30, 2013 at 7:53 AM, Michael Richardson
<mcr+ietf@sandelman.ca> wrote:
>
> cb.list6 <cb.list6@gmail.com> wrote:
>     > On Jul 30, 2013 4:46 AM, "Michael Richardson" <mcr+ietf@sandelman.ca> wrote:
>     >>
>     >>
>     >> Cameron, which scenario does the Android AOSP use?
>
>     > Aosp has not integrated this yet, but this implementation was submitted
>
>     > http://dan.drown.org/android/clat/
>
>     > Scenario 2 is  used. There is value in the device being able maintain
>     > communication (sockets) while tethering is turned on and off. Voip is a good
>     > example of something that should not bounce when tethering is turned on
>
> I don't understand.
> Why does adding a second IP address change anything that is already alive?
>

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

Are you suggesting that we simply keep the /128 on the WAN and put the
/64 on the LAN with normal SLAAC and new LAN inteface IP?  The issue
with that, is that on the LAN, the /128 on the WAN is not accounted
for and may cause a conflict / duplicate, so it is easier to make the
WAN and LAN intefaces IP the same


CB
> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
>
>

v2.23.0 | Report a Bug | By Email