Re: I-D Action: draft-mishra-6man-variable-slaac-01.txt

JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Mon, 09 November 2020 09:52 UTC

Return-Path: <prvs=158289e994=jordi.palet@consulintel.es>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FB343A0DD7 for <ipv6@ietfa.amsl.com>; Mon, 9 Nov 2020 01:52:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es
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 zIMmukJWDK4c for <ipv6@ietfa.amsl.com>; Mon, 9 Nov 2020 01:52:51 -0800 (PST)
Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) by ietfa.amsl.com (Postfix) with ESMTP id 679233A0DD5 for <ipv6@ietf.org>; Mon, 9 Nov 2020 01:52:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1604915569; x=1605520369; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=7h6O/rpL V8gsrX2DGI5H/1YgApDdKZZPH3VejRNom/4=; b=UlDuO/8I5cJmm/LghnKm9UcA tvAM8+W2qCrQwj4h+B5KtJET/6fwiq+o0eSdvqTZ0oPuva09JQTDUr4sYL9dDzaD 2R9lPmI+t06WiAwhDl62tY3Se7WgGj+NlXB2QBSX1EkGsYB3uHU/KwE6uMON9aMk zI396+zIzEEqRfV/6cI=
X-MDAV-Result: clean
X-MDAV-Processed: mail.consulintel.es, Mon, 09 Nov 2020 10:52:49 +0100
X-Spam-Processed: mail.consulintel.es, Mon, 09 Nov 2020 10:52:48 +0100
Received: from [10.10.10.144] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50000458584.msg for <ipv6@ietf.org>; Mon, 09 Nov 2020 10:52:48 +0100
X-MDRemoteIP: 2001:470:1f09:495:d41d:ff88:9a6d:5019
X-MDHelo: [10.10.10.144]
X-MDArrival-Date: Mon, 09 Nov 2020 10:52:48 +0100
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Return-Path: prvs=158289e994=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: ipv6@ietf.org
User-Agent: Microsoft-MacOutlook/16.42.20101102
Date: Mon, 09 Nov 2020 10:52:46 +0100
Subject: Re: I-D Action: draft-mishra-6man-variable-slaac-01.txt
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: 6man WG <ipv6@ietf.org>
Message-ID: <BE1CC889-3BA3-4A95-9065-7972C7E174ED@consulintel.es>
Thread-Topic: I-D Action: draft-mishra-6man-variable-slaac-01.txt
References: <160409741426.1448.16934303750885888002@ietfa.amsl.com> <3c1c3ab5-5726-b141-e7ed-618984bbbdb1@gmail.com> <CABNhwV1zoZpZNjb54rEys4+49H3vpebZW2g9JbO1_58eR+WnQg@mail.gmail.com> <CAKD1Yr0vvyQnTGRoSh4qa4He1gq5HXXRaKU3pVLtCtDUzcwL_w@mail.gmail.com> <CAD6AjGQPatbg5=OaMzxJXy5mGZai1bqLfg8f+9SUnfg=s1kADg@mail.gmail.com> <FE260932-A064-493E-8CD5-D92B2725F9E6@employees.org> <CAD6AjGRXYqJhXL6ipbS_cWkE2mg3sU4tM5XCCvgiGvSALGfeeg@mail.gmail.com> <e7938c0f-758c-1f90-814a-46f8b262a134@gmail.com> <4f6d39bc-c7cb-fd44-dcef-1bab3f08a567@gmail.com>
In-Reply-To: <4f6d39bc-c7cb-fd44-dcef-1bab3f08a567@gmail.com>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/VQ9NYwcpz8Gdh1HThlcNB9xdjr0>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Nov 2020 09:52:52 -0000

There are many solutions for that, and in fact, some of them, not "in RFCs" are being used.

For example, you can use by default the first /64 for the WAN link, then 2nd one for the smartphone itself, then the rest don't need to be standardized. In fact, which one uses the smartphone itself is not needed.

See RFC3633, and also https://tools.ietf.org/html/draft-palet-v6ops-p2p-links-04.

In fact, I recall having seen some slides or document indicating that each /64 allocated to a smartphone is actually a /60 and part of it is the p2p link, but I'm not sure if that was before the actual standards, just an idea, or actual standards. I need to find that document to make sure ....

... Just found it! https://www.rmv6tf.org/wp-content/uploads/2012/11/Cisco_Suthar_Designing-LTE-with-IPv6_26-April-20111.pdf


Regards,
Jordi
@jordipalet
 
 

El 9/11/20 10:35, "ipv6 en nombre de Alexandre Petrescu" <ipv6-bounces@ietf.org en nombre de alexandre.petrescu@gmail.com> escribió:



    Le 09/11/2020 à 02:25, Brian E Carpenter a écrit :
    > On 09-Nov-20 13:00, Ca By wrote:
    >> 
    >> 
    >> On Fri, Nov 6, 2020 at 1:05 AM <otroan@employees.org 
    >> <mailto:otroan@employees.org>> wrote:
    [...]
    > Just handing out a /56 to each PDP context would be so much better.

    Sounds reasonable because a /56 is so much space, and can make several /64s.

    But still, it would not be enough.  How would the smartphone form an
    IPv6 address when receiving a /56 in the RA?  There is no spec that
    tells it how to, because the IID must be 64bit and the smartphone would
    not know how to pad the remaining 8 bits.

    At that point the operator might want to put a /64 in an RA and also
    respond to DHCPv6-PD with a /56 inside.  It would be a double address
    architecture effort.

    This is why I am wondering how would one think the smartphone would be
    happy enough when receiving a /56 in a DHCPv6 advertisement.

    Alex

    > 
    > Brian
    > 
    >> 
    >> None of that exists today in mobile. I feel the effort and scale 
    >> are daunting, so i am not going to do it.
    >> 
    >> But, getting a knob in the gateway to set the RA to be 60 (or 
    >> other) instead of 64 would be easy. And, that knob could be 
    >> constrained to only compatible device type (chef’s kisses!)... it 
    >> can be done
    >> 
    >> 
    >> 
    >> Best regards, Ole
    >> 
    >> 
    >> --------------------------------------------------------------------
    >>
    >>
    >>
    >> 
    IETF IPv6 working group mailing list
    >> ipv6@ietf.org Administrative Requests: 
    >> https://www.ietf.org/mailman/listinfo/ipv6 
    >> --------------------------------------------------------------------
    >>
    >

    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    ipv6@ietf.org
    Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    --------------------------------------------------------------------



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.