Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt

"Brzozowski, John" <John_Brzozowski@Cable.Comcast.com> Fri, 23 October 2015 12:57 UTC

Return-Path: <John_Brzozowski@cable.comcast.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A96321B36ED for <v6ops@ietfa.amsl.com>; Fri, 23 Oct 2015 05:57:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.225
X-Spam-Level:
X-Spam-Status: No, score=0.225 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
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 gLhxHb6nz8Mq for <v6ops@ietfa.amsl.com>; Fri, 23 Oct 2015 05:57:01 -0700 (PDT)
Received: from pacdcmhout01.cable.comcast.com (PACDCMHOUT01.cable.comcast.com [68.87.31.167]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DCF61B36EE for <v6ops@ietf.org>; Fri, 23 Oct 2015 05:57:01 -0700 (PDT)
X-AuditID: 44571fa7-f79626d0000011ff-27-562a2e9b0895
Received: from PACDCEXHUB01.cable.comcast.com (cas-umc02.ndceast.pa.bo.comcast.net [68.87.34.28]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by pacdcmhout01.cable.comcast.com (SMTP Gateway) with SMTP id 72.D1.04607.B9E2A265; Fri, 23 Oct 2015 08:56:59 -0400 (EDT)
Received: from PACDCEX41.cable.comcast.com (24.40.2.140) by PACDCEXHUB01.cable.comcast.com (24.40.56.114) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 23 Oct 2015 08:56:59 -0400
Received: from PACDCEX41.cable.comcast.com (24.40.2.140) by PACDCEX41.cable.comcast.com (24.40.2.140) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Fri, 23 Oct 2015 08:56:58 -0400
Received: from PACDCEX41.cable.comcast.com ([fe80::3aea:a7ff:fe36:8b0c]) by PACDCEX41.cable.comcast.com ([fe80::3aea:a7ff:fe36:8b0c%19]) with mapi id 15.00.1044.021; Fri, 23 Oct 2015 08:56:58 -0400
From: "Brzozowski, John" <John_Brzozowski@Cable.Comcast.com>
To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Thread-Topic: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
Thread-Index: AQHRDMu3n1oaXPpdb0m/H+tIWUdOwp55AYUAgAAJeoA=
Date: Fri, 23 Oct 2015 12:56:57 +0000
Message-ID: <D24FA4B7.18DE45%john_brzozowski@cable.comcast.com>
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <5628DAD7.1010203@gmail.com> <D24E55FD.18D5AF%john_brzozowski@cable.comcast.com> <5628E3DA.4010905@gmail.com> <D24E6507.18D65D%john_brzozowski@cable.comcast.com> <56290B90.8000400@gmail.com> <D24E8B67.18D713%john_brzozowski@cable.comcast.com> <5629EE64.1060402@gmail.com>
In-Reply-To: <5629EE64.1060402@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.5.7.151005
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [68.87.29.8]
Content-Type: text/plain; charset="utf-8"
Content-ID: <D21AD6B751EE164387F2C1EB4C29F495@cable.comcast.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Forward
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPIsWRmVeSWpSXmKPExsXiEq4koztbTyvMYPIaa4uTZ56wWZw+tpfZ gclj56y77B5LlvxkCmCK4rJJSc3JLEst0rdL4Mpo6jvEXnCisuLy6jmMDYw7yroYOTkkBEwk mpb1MkLYYhIX7q1n62Lk4hAS2MUk8WHrb0YIZy+jxMeuF+wQzm5GiR1fTzODtAgJnATKXM8A sdkEbCRef/gJNkpEwFTix64nLF2MHBzMAqoSs//wg4SFBaIldmzpZ4MoiZGY9aKRCaRERMBK YudcJZAwC1D1h3OHwEp4Bewl5jyYxgqxtp9ZYtvTT+wgCU4BTYn2yevBTmAEuvr7qTVMIDaz gLjErSfzmSC+EZBYsuc8M4QtKvHy8T9WEFtUQE+i/dR/Noi4gcTWpftYIGw5iZ4drYwQJ2tK rN+lDzHSQeLUnA42CFtRYkr3Q3aI2wQlTs6E+FAIaOS8B9IQU8QlDh/ZwTqBUXYWkoNmIQyd hWToLCRDZyEZuoCRdRWjXEFickpybkZ+aYmBoV5yYlJOql5yfm5yYnEJiN7ECE4G8st3MN57 4XSIUYCDUYmHV1leK0yINbGsuDL3EKMEB7OSCO9pHaAQb0piZVVqUX58UWlOavEhRmkOFiVx 3s33foUKCaQnlqRmp6YWpBbBZJk4OKUaGAUT85tO/Z5o3Gs2XfHTq5mMGRlNRaw7Omdtd3wy L3fKvt/ftdZbz/bukdrm5b+UYU0+p70Aw+m7Xw6nX520wcltX8q+Quc3XQI/jzbYTL2ccay9 rCDl6cWUKZyN8u1J+5ZddHgU93yDdSvnnr21FzRcSnmmiyQucNwhLvXz7CTrOt+UrX0vpyix FGckGmoxFxUnAgD/o5wdAgMAAA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/4KCs1LFXmDmYVibyCmigz7echlU>
Cc: "v6ops@ietf.org" <v6ops@ietf.org>
Subject: Re: [v6ops] Fwd: I-D Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
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, 23 Oct 2015 12:57:03 -0000

Alexander,

We have based our work on data that tells us what sort of devices
(including operating systems) are appearing on Wi-Fi networks, our Wi-Fi
networks.  To ensure we meet our customer’s expectations we use this data
as a cornerstone for our design and planning.  As new devices appear there
are two choices I see based on my experience:

* New devices (like the ones you are citing) are implemented to be
compatible with standards and hence existing deployments
* New devices implement additional/experimental functionality (like what
you describe) while remaining compatible with existing standards and
deployments

Given the above, support for new, experimental functionality could be
planned in an incremental fashion if required.

John




-----Original Message-----
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Date: Friday, October 23, 2015 at 04:23
To: John Jason Brzozowski <john_brzozowski@cable.comcast.com>
Cc: v6ops <v6ops@ietf.org>
Subject: Re: [v6ops] Fwd: I-D Action:
draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt

>Yes, thanks.
>
>As a network operator it is good to accommodate as many devices as
>possible and that goes way beyond the current smartphones like the ones
>you cite.
>
>Alex
>
>Le 22/10/2015 19:08, Brzozowski, John a écrit :
>> We can consider this for future work.
>>
>> To date we have tested with a wide range of Android, Apple, and Windows
>> Wi-Fi enabled devices.  All have been verified and work properly, as
>>such
>> we have not excluded any devices.  Our goal has been to be as inclusive
>>as
>> possible.  What is documented is, in general, what will be rolled out.
>>
>> John
>> +1-484-962-0060
>>
>>
>>
>>
>> -----Original Message-----
>> From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
>> Date: Thursday, October 22, 2015 at 12:15
>> To: John Jason Brzozowski <john_brzozowski@cable.comcast.com>
>> Cc: v6ops <v6ops@ietf.org>
>> Subject: Re: [v6ops] Fwd: I-D Action:
>> draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
>>
>>>
>>>
>>> Le 22/10/2015 16:06, Brzozowski, John a écrit :
>>>> Ole responded to the use of the /63.
>>>
>>> Well.
>>>
>>>> Regarding your use of this, I am curious which implementation and how
>>>> many
>>>> devices are operating using a /63?
>>>
>>> If the goal is to minimize the importance of a small number of devices
>>> then the goal is reached.
>>>
>>> The implementation is with linux, radvd software and a PMIP
>>> implementation.
>>>
>>> The question of 63 is little dependent on PMIP.
>>>
>>> If the question is about whether a Host can use SLAAC to self-configure
>>> an address out of a /63 then the answer is yes.  The implementation
>>> inserts a 0 at the 64th position.  Everybody does that, nobody inserts
>>>a
>>> 1.
>>>
>>> Am I answering?
>>>
>>>> Finally, someone from Google/Android will have to comment on Android
>>>>and
>>>> DHCPv6 for PD support.  I also believe Apple does not support PD yet
>>>>on
>>>> their devices either.  Like the draft says this is future work, we
>>>>will
>>>> see where this goes.
>>>
>>> Instead of further work we can just modify a number (64 to 63).
>>>
>>> Alex
>>>
>>>>
>>>> John
>>>> +1-484-962-0060
>>>>
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
>>>> Date: Thursday, October 22, 2015 at 09:25
>>>> To: John Jason Brzozowski <john_brzozowski@cable.comcast.com>
>>>> Cc: v6ops <v6ops@ietf.org>
>>>> Subject: Re: [v6ops] Fwd: I-D Action:
>>>> draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
>>>>
>>>>>
>>>>>
>>>>> Le 22/10/2015 15:15, Brzozowski, John a écrit :
>>>>>> Thanks for the comments, see below.
>>>>>>
>>>>>> -----Original Message-----
>>>>>>
>>>>>> From: v6ops <v6ops-bounces@ietf.org> on behalf of Alexandre Petrescu
>>>>>>    <alexandre.petrescu@gmail.com> Date: Thursday, October 22, 2015
>>>>>>at
>>>>>> 08:47 To: v6ops <v6ops@ietf.org> Subject: Re: [v6ops] Fwd: I-D
>>>>>> Action: draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt
>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> Assigning a prefix-per-host in a WiFi deployment, rather than an
>>>>>>> individual addresses within a same prefix, has also been
>>>>>>> considered in Proxy Mobile IP deployments and it works ok.  It has
>>>>>>> some advantages, and some inconvenients, depending how it's done.
>>>>>>>
>>>>>>> I have some comments on the draft.
>>>>>>>
>>>>>>> draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt says:
>>>>>>>> If radius server discovers that the UE/ subscriber is a fresh
>>>>>>>> device trying to gain access onto the Wi-Fi network it will
>>>>>>>> identify some parameters (e.g.  IPv6 /64 prefix)
>>>>>>> [...]
>>>>>>>> This RA contains a few important parameters for the EU/
>>>>>>>> subscriber to consume: (1) a /64 prefix and (2) flags.
>>>>>>>
>>>>>>> I would like to suggest to substitute /63 for /64 throughout the
>>>>>>> document.  A /64 will not allow smartphones to tether cleanly.
>>>>>>
>>>>>> [jjmb] I believe an RA with a PIO of a /63 will be problematic,
>>>>>
>>>>> Why?
>>>>>
>>>>>> we have already tested the use of a /64 and will likely maintain
>>>>>> this for our deployment of IPv6 for community Wi-Fi.
>>>>>
>>>>> Well it is good for that community.
>>>>>
>>>>> In this respect, I dont think what the community uses should be an
>>>>> example for other communities (a BCP).
>>>>>
>>>>> I use 63 and works fine.
>>>>>
>>>>>> For tethering over Wi-Fi our expectation is that DHCPv6 PD would be
>>>>>> utilized.
>>>>>
>>>>> I hear Android not supporting DHCP at this time, so PD would be a
>>>>>pain.
>>>>>
>>>>> On another hand, just change 64 to 63 will make tethering smartphones
>>>>> work fine without needing DHCP, nor DHCP-PD.
>>>>>
>>>>>>> For a discussion of why 64 one can refer to RFC7521 "Analysis of 64
>>>>>>> boundary..."
>>>>>>>
>>>>>>> For a discussion of why 63 - where to start?
>>>>>>>
>>>>>>> draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt says:
>>>>>>>> The WLAN-GW will use the received Radius information to compose
>>>>>>>> the response to the UE/subscriber originated RS message.  The
>>>>>>>> WLAN-GW will answer using a unicast RA (Router Advertisement) to
>>>>>>>> the UE/ subscriber.  This RA contains a few important parameters
>>>>>>>> for the EU/ subscriber to consume: (1) a /64 prefix and (2)
>>>>>>>> flags.
>>>>>>>
>>>>>>> Since a captive portal is used, it would make sense to use the
>>>>>>> Captive Portal IPv6 RA Option as well
>>>>>>> (draft-wkumari-dhc-capport-16 LC'ed towards RFC end of September).
>>>>>> [jjmb] we will take a look at this draft to determine applicability.
>>>>>> Stay tuned.
>>>>>>>
>>>>>>> draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt says:
>>>>>>>> When a new UE connects to the community Wi-Fi it connects to the
>>>>>>>> Wi- Fi network by attaching to the relevant 'open' SSID
>>>>>>>> advertised for use as part of the community Wi-Fi offering.
>>>>>>>
>>>>>>> But some community networks use a 'hidden' SSID, known only by
>>>>>>> members of that community.
>>>>>> [jjmb] hidden should work as well, providing the end user knows the
>>>>>> name of the SSID.  We will look to see if there are clarifications
>>>>>> we can make to address this.
>>>>>
>>>>> Ok.
>>>>>
>>>>> Alex
>>>>>
>>>>>>>
>>>>>>> Yours,
>>>>>>>
>>>>>>> Alex
>>>>>>>
>>>>>>>
>>>>>>> Le 20/10/2015 20:35, Fred Baker (fred) a écrit :
>>>>>>>> Posted yesterday. Your comment solicited.
>>>>>>>>
>>>>>>>>> Begin forwarded message:
>>>>>>>>>
>>>>>>>>> From: internet-drafts@ietf.org Subject: I-D Action:
>>>>>>>>> draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt Date:
>>>>>>>>> October 19, 2015 at 12:50:01 PM PDT To:
>>>>>>>>> <i-d-announce@ietf.org> Reply-To: internet-drafts@ietf.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> A New Internet-Draft is available from the on-line
>>>>>>>>> Internet-Drafts directories.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Title           : Unique IPv6 Prefix Per Host Authors : John
>>>>>>>>> Jason Brzozowski Gunter Van De Velde Filename        :
>>>>>>>>> draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt Pages : 14
>>>>>>>>> Date : 2015-10-19
>>>>>>>>>
>>>>>>>>> Abstract: In some IPv6 environments the need has arisen for
>>>>>>>>> hosts to be able to utilise a unique IPv6 prefix even though
>>>>>>>>> the link or media may be shared.  Typically hosts
>>>>>>>>> (subscribers) on a shared network, like Wi- Fi or Ethernet,
>>>>>>>>> will acquire unique IPv6 addresses from a common IPv6 prefix
>>>>>>>>> that is allocated or assigned for use on a specific link.
>>>>>>>>> Benefits of a unique IPv6 prefix compared to a unique IPv6
>>>>>>>>> address from the service provider are going from enhanced
>>>>>>>>> subscriber management to improved isolation between
>>>>>>>>> subscribers.
>>>>>>>>>
>>>>>>>>> In most deployments today IPv6 address assignment from a single
>>>>>>>>> IPv6 prefix on a shared network is done by either using IPv6
>>>>>>>>> stateless address auto-configuration (SLAAC) and/or stateful
>>>>>>>>> DHCPv6.  While this is still viable and operates as designed
>>>>>>>>> there are some large scale environments where this concept
>>>>>>>>> introduces significant performance challenges and implications,
>>>>>>>>> specifically related to IPv6 router and neighbor discovery.
>>>>>>>>> This document outlines an approach utilising existing IPv6
>>>>>>>>> protocols to allow hosts to be assigned a unique IPv6 prefix
>>>>>>>>> (instead of a unique IPv6 address from a shared IPv6 prefix).
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The IETF datatracker status page for this draft is:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 
>>>>>>>>>https://datatracker.ietf.org/doc/draft-jjmb-v6ops-unique-ipv6-pref
>>>>>>>>>ix
>>>>>>>>> -p
>>>>>>>>> er
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>> -host/
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>> There's also a htmlized version available at:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 
>>>>>>>>>https://tools.ietf.org/html/draft-jjmb-v6ops-unique-ipv6-prefix-pe
>>>>>>>>>r-
>>>>>>>>> ho
>>>>>>>>> st
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>> -00
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>> Please note that it may take a couple of minutes from the time of
>>>>>>> submission
>>>>>>>>> until the htmlized version and diff are available at
>>>>>>>>> tools.ietf.org.
>>>>>>>>>
>>>>>>>>> Internet-Drafts are also available by anonymous FTP at:
>>>>>>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>>>>>>
>>>>>>>>> _______________________________________________ I-D-Announce
>>>>>>>>> mailing list I-D-Announce@ietf.org
>>>>>>>>> https://www.ietf.org/mailman/listinfo/i-d-announce
>>>>>>>>> Internet-Draft directories: http://www.ietf.org/shadow.html or
>>>>>>>>>    ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________ v6ops mailing
>>>>>>>> list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________ v6ops mailing list
>>>>>>>    v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>