Re: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info)

Erik Kline <ek@google.com> Fri, 29 September 2017 08:01 UTC

Return-Path: <ek@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 87614134481 for <v6ops@ietfa.amsl.com>; Fri, 29 Sep 2017 01:01:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qCqaZ46Ecj8W for <v6ops@ietfa.amsl.com>; Fri, 29 Sep 2017 01:00:59 -0700 (PDT)
Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E6DF12895E for <v6ops@ietf.org>; Fri, 29 Sep 2017 01:00:58 -0700 (PDT)
Received: by mail-wr0-x231.google.com with SMTP id a43so988247wrc.0 for <v6ops@ietf.org>; Fri, 29 Sep 2017 01:00:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FYpqP9AdzjGFkTSU0d0gxbgh0DF5AXRgh67A2iw8A8g=; b=e/+e0NvplwlrDsBxz3HonWwuGRFaQmQEU1/bfwZZLp/v/6OC1MM4Uj0kSeGXJ9vkrV XjwSo6TXs+nnYH/9kbcu/cM+bxnZblPgCPiHrV++6VZ6lqampfHqR/LDYnnRCFN65iQx tag0nxL1MyJaIDclV3wpd6aRDhF/mvnZZ6fZAQG3D5yVjVp6N6gq2593l8MvCH3AT0xu DESFLTUePtvdSCI4Qb0eeSLBWzWB6z1zOB1vxIXa7Nzbj3wHoYN7Cvk7y9idVbgdpcvR nkORT6fMSMD/AtHtnieGLUC1BPBBiM1vjqtE27ncWWexHwU8zSZ9NvEeRhJC2bl/IwGm iNcA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FYpqP9AdzjGFkTSU0d0gxbgh0DF5AXRgh67A2iw8A8g=; b=nyElavC7Y0T2zjyB3cC8LpnUN+CcCcT//Q20hklxKEVQk+tfd7UhBrsYBvNtI0tTES HCEndxRdPbPwNYJSwyVAhk2ppA2HXcY20DnohntdYtS19wcxx6fA3Ok9osZbR1UyK8Fq uhHtRUiAzbg7G2g2YKd94n503F3s+C0yWcDPf+MLSsdgxFaNOSs/obJPJDl7Vh85J5p4 jXkm4AFVhCTX8Nya28Od0tFc3usv1hAaqIQItdQzsv0S4vRSH9BoBGnJuU+7z9ut5L2M 3TAmId9sT0BsbsuP4jkJJwjh13hClT6AlzS5P2UalFfa8Qy5udXxb62ujCsfIhG/zXTV jYTQ==
X-Gm-Message-State: AHPjjUisQgLtRgqitzJNQ+ltN1ECv+B40g4o5f66Rye5GtI+0fkeF1pN eR65+KJltoDkTT2hFR9007iz+H1MpevotdqUl67Y6Q==
X-Google-Smtp-Source: AOwi7QANusYy8sogJohPo46sCx3tqbxPkMq4zMApQUnCLecWSVUObCgYqYMH9N1eQuYagsZY3ASkgcWTglMGHRwOJu8=
X-Received: by 10.223.171.74 with SMTP id r10mr7385933wrc.86.1506672056791; Fri, 29 Sep 2017 01:00:56 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.213.9 with HTTP; Fri, 29 Sep 2017 01:00:35 -0700 (PDT)
In-Reply-To: <0bc67bdb-a62e-b3aa-9dad-afe589b0d230@gmail.com>
References: <LO1P123MB01168388285206BB7C26F029EA7A0@LO1P123MB0116.GBRP123.PROD.OUTLOOK.COM> <46045DAA-9096-43BA-A5FD-571232767726@google.com> <CAKD1Yr3vziaHfkR+hQ7QHXaz7QraKH2HLUVXUW63GpnOAj4JoQ@mail.gmail.com> <E72C3FBE-57A4-4058-B9E5-F7392C9E9101@google.com> <LO1P123MB0116805F9A18932E2D0694FEEA780@LO1P123MB0116.GBRP123.PROD.OUTLOOK.COM> <1496304E-54BE-47FA-A7F1-1AA6E163DAB1@employees.org> <CAD6AjGQdMFgv4727wHm41HmEyo2Z-PCabPHPSRSVwOi_rey7OQ@mail.gmail.com> <CAKD1Yr03zsuSBqPegs6RNbBqnJizUOLZwH+rNDi1Ocg4k+mARQ@mail.gmail.com> <20170928030630.DD2D08867238@rock.dv.isc.org> <alpine.DEB.2.20.1709280753080.18564@uplift.swm.pp.se> <20170928074105.BCB99886E538@rock.dv.isc.org> <alpine.DEB.2.20.1709280955490.18564@uplift.swm.pp.se> <20170928081527.21D9F886EF0C@rock.dv.isc.org> <CAAedzxqRar=X6c6WJNOWtKA3S6Dx8nXcuwYYh8OyK3oncJYnsQ@mail.gmail.com> <alpine.DEB.2.20.1709281052430.18564@uplift.swm.pp.se> <CAAedzxobp6ORODchDGqjbjfKuiZ1vO+q4k5so74MLqdpCzY84A@mail.gmail.com> <0bc67bdb-a62e-b3aa-9dad-afe589b0d230@gmail.com>
From: Erik Kline <ek@google.com>
Date: Fri, 29 Sep 2017 17:00:35 +0900
Message-ID: <CAAedzxpPgtH8SCPPiSqmo1wTzp6d8=58oHg8=iTcQhySoSLXDQ@mail.gmail.com>
To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Cc: "v6ops@ietf.org" <v6ops@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c1b5342c5bb05055a4f6c6d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/uehNQOwiEWr8E9nHv6vGBwf4amI>
Subject: Re: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 29 Sep 2017 08:01:06 -0000

On 29 September 2017 at 16:39, Alexandre Petrescu
<alexandre.petrescu@gmail.com> wrote:
> Hi Erik,
>
>
> Le 28/09/2017 à 11:06, Erik Kline a écrit :
>>
>> On 28 September 2017 at 17:53, Mikael Abrahamsson <swmike@swm.pp.se>
>> wrote:
>>>
>>> On Thu, 28 Sep 2017, Erik Kline wrote:
>>>
>>>> I can just feel all the "android and dhcpv6" screeds being
>>>> written right now...
>>>
>>>
>>>
>>> Do any other mobile operating systems do DHCPv6 on the GTP tunnel?
>>> It's been too many years since I last looked at GTP packet traces
>>> to remember if this was done or not.
>>
>>
>> I've no idea.  Nor do I know what might happen to various networks
>> if DHCPv6 requests were to be made on the mobile interface (even if
>> the O bit /were/ observed to be set).  The stories of billing system
>> crashes and so on from the early days of v6 on mobile leave me
>> somewhat suspicious.
>>
>> I have been wondering about asking for an API to the modem to query for
>> the 3GPP release number of the network as a hint for expected capabilities,
>> but that kinda seems both excessive and like a
>> layering violation.  ;-)
>
>
> I heard about a recent IETF protocol "DLEP" that communicates between
> the computer and the modem.  Looking at it I see it has a 'Status'
> message in which one could probably put that 3GPP release number semantics.

https://tools.ietf.org/html/rfc8175 does indeed look quite interesting, thanks!