Re: [6lowpan] Ready for WGLC? (Re: Latest version of IPv6 over BT-LE draft)

["Dijk, Esko" <[e-mail]>]

Dear Teemu,

thanks for your detailed answer. I agree that details on prefix allocation are out of scope. Still, it's good to verify that the practically available options cover the use cases that are envisioned for 6LoWPAN over BT-LE. The draft-ietf-v6ops-3gpp-eps-07 provides assurance that this will be possible in 3G connectivity situations.

IPv6 Neighbor Discovery Proxy (RFC 4389) could be an option. But I deduce from the BT-LE draft that 6lowpan-ND (normative reference) is to be used so this would require a version of ND Proxy adapted to 6lowpan context (such as draft-maqueda-6lowpan-pgw-00), or not?

For the situation of home network (eg WiFi) connectivity of the BT-LE Master device / 6LBR, some issues may appear such as the need for routing in multi-subnet home networks to ensure end-to-end IPv6 connectivity between all networked devices in a home. For example, there could be other 6LoWPAN 802.15.4 devices connected to another 6LBR. But I just found that is discussed in the HomeNet WG (draft-chown-homenet-arch-00 and the related list discussions) so no need perhaps to discuss further here.

best regards,
Esko

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of [e-mail]
Sent: Friday 23 September 2011 10:38
To: [e-mail]
Subject: Re: [6lowpan] Ready for WGLC? (Re: Latest version of IPv6 over BT-LE draft)

(just joined this list)

I do not believe normative text about from where 6LBR gets prefixes it uses to number BT-LE network is mandatory for "IPv6 over BT-LE" document. A tool for obtaining prefixes, which can be used on BT-LE network, is used on 6LBR's "non-BT-LE" WAN interface and hence has nothing to do with BT-LE.

That said, the 6LBR could utilize multitude of tools, for example:
- DHCPv6 Prefix Delegation is a possibility when 6LBR's WAN interface is cellular and ISP providers DHCPv6 Prefix Delegation service. Also if WAN is fixed network, then the fixed-line ISP may also provide DHCPv6 PD services
- IPv6 Neighbor Discovery Proxy technology is also possibility, in which case 6LBR "bridges" the (/64) prefix it has on WAN (cellular) interface to BT-LE network
- Prefix generated as described by 6to4 is possibility if 6LBR has only public IPv4 address in its WAN interface (it can use that to build IPv6 prefix)
- Autogenerated ULA prefix is also possibility, if only "site local" communication is required
- NAT66 is possibility, although very evil of course☺ In that case 6LBR would advertise e.g. autogenerated ULA prefix for BT-LE and then NAT communications using local addresses to public IPv6
- Static prefixes could be used, and those could be configured manually or provided via some provisioning system

And of course if only local communications are needed (6LBR acts as proxy), then of course no prefix is needed at all and communications with link-local addresses is enough.

And so forth, i.e. the 6LBR can get the prefixes from the source best suited for the deployment scenario at hand. Maybe it would be worth clarifying that the exact tool 6LBR uses is out of scope of this document?

In 3GPP based cellular accesses the handsets will prefer DHCPv6 Prefix Delegation (standardized in 3GPP Release-10 but could be used sooner as well), but if DHCPv6 PD is not supported by handset or network, then ND Proxy is the likeliest technology to choose. In 3GPP access the phone gets at least one /64 for its WAN interface, which can be shared locally as well.

For 3GPP addressing details please see: draft-ietf-v6ops-3gpp-eps-07 section 5.

Best regards,

        Teemu


>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On
>Behalf Of Xi Minjun (Nokia-NRC/Beijing)
>Sent: 23 September, 2011 10:43
>To: [e-mail]; Nieminen Johanna.1 (Nokia-NRC/Helsinki);
>[e-mail]
>Cc: [e-mail]
>Subject: Re: [6lowpan] Ready for WGLC? (Re: Latest version of IPv6 over
>BT-LE
>draft)
>
>Sorry about that, I misunderstood your question. I have no idea about
>which prefix should be generated by the 6LBR, which is really one big issue.
>--
>Best Regards,
>Minjun, Xi
>Nokia Research Center
>
>-----Original Message-----
>From: ext Dijk, Esko [mailto:[e-mail]]
>Sent: Thursday, September 22, 2011 10:59 PM
>To: Xi Minjun (Nokia-NRC/Beijing); Nieminen Johanna.1
>(Nokia-NRC/Helsinki); [e-mail]
>Cc: [e-mail]
>Subject: RE: [6lowpan] Ready for WGLC? (Re: Latest version of IPv6 over
>BT-LE
>draft)
>
>Hello  Minjun,
>
>I don't see an issue in IPv6 address configuration in 6LNs / section 3.2.1.
>Rather the question is how the 6LBR (phone) obtains IP prefix(es). I
>was curious whether a cellular operator would provide either
>  1) an IPv6 prefix (which the phone could further use for prefix
>distribution into the LoWPAN)
>  2) an IPv6 address (in which case the phone needs some other
>mechanism to obtain an IPv6 prefix - see below)
>
>Quote from draft-ietf-6lowpan-nd:
>
>   The 6LBRs are responsible for managing the prefix(es) assigned to the
>   6LoWPAN, using manual configuration, DHCPv6 Prefix Delegation
>   [RFC3633], or other mechanisms. In an isolated LoWPAN a ULA
>   [RFC4193] prefix SHOULD be generated by the 6LBR.
>
>If more is known how this is going to work eg for the topology in Fig
>5, we could consider to write it in the I-D.
>
>Esko
>
>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]]
>Sent: Thursday 22 September 2011 15:53
>To: Dijk, Esko; [e-mail]; [e-mail]
>Cc: [e-mail]
>Subject: Re: [6lowpan] Ready for WGLC? (Re: Latest version of IPv6 over
>BT-LE
>draft)
>
>Esko,
>DHCPv6 for 6LoWPAN network.
>
>In the current version of I-D, there's one chapter (3.2.1) describing
>"IPv6 Address Configuration", which mentioned "Stateless
>autoconfiguration".
>Stateless autoconfiguration is defined in RFC4862, which is different
>from "stateful autoconfiguration" (aka DHCPv6).
>
>Compared with 6LoWPAN over BT-LE, draft-ietf-6lowpan-nd has defined the
>mechanism to configure IPv6 addresses for 6LoWPAN over 802.15.4. In
>draft- ietf-6lowpan-nd-17, there're several assumptions for 6lowpan-nd.
>It says "All nodes in the network have an EUI-64 interface identifier
>in order to do address auto-configuration and detect duplicate addresses."
>Also, draft-ietf-6lowpan-nd introduces the Address Registration
>mechanism and the optional DAD mechanism. DHCPv6 is not optimized for
>low-power and lossy networks including 802.15.4 and BT-LE.
>
>I think it is necessary to make the "IPv6 address configuration" for
>6LoWPAN over BT-LE clear in the future revision.
>
>Thank you!
>
>--
>Best Regards,
>Minjun, Xi
>Nokia Research Center
>
>
>
>
>
>On 9/19/11 9:54 PM, "ext Dijk, Esko" <[e-mail]> wrote:
>
>>Dear BT-LE authors, all,
>>
>>I haven't done a detailed review but I have one technical
>>comment/question. The typical case in the I-D is a BT-LE mobile phone,
>>connected to the internet, acting as a 6LBR and distributing an IP
>>prefix to 6LNs. Is it the intention that an IP prefix for the 6LoWPAN
>>can be obtained by the phone via DHCPv6 ?  If so would an ISP support
>>this for a phone connected to their 3G network?
>>
>>Obtaining an IP prefix by the 6LBR seems necessary to enable routing
>>from a host on the internet to a 6LN.
>>
>>regards,
>>Esko
>>
>>
>>Esko Dijk
>>
>>Philips Corporate Technologies, Research High Tech Campus 34,
>>Eindhoven, The Netherlands [e-mail]
>>
>>
>>
>>
>>-----Original Message-----
>>From: [e-mail] [mailto:[e-mail]] On
>>Behalf Of Carsten Bormann
>>Sent: Friday 9 September 2011 14:43
>>To: [e-mail]
>>Subject: [6lowpan] Ready for WGLC? (Re: Latest version of IPv6 over
>>BT-LE
>>draft)
>>
>>6LoWPANners,
>>
>>we are now looking at the third WG version (-02) of this draft.
>>
>>Are we ready to do a working-group last-call on this?
>>
>>-- if you see something major that needs to be done before this is
>>ready, please speak up now.
>>   (If you have technical comments, or maybe some editorial
>>suggestions, these are also useful at this point, although there also
>>will be time to comment in the actual WGLC.)
>>
>>-- conversely, if you have reviewed the document and like it, please
>>do speak up (and please do say what you have specifically looked at).
>>
>>Of course, we don't want to go into a WGLC with glaring omissions (I
>>gather Appendix A is not really a necessary part of this spec), and we
>>also don't want to go into WGLC if the working group hasn't been able
>>to review the document or, worse, if nobody actually cares.
>>
>>Please respond to this message by Sep 16.
>>
>>Gruesse, Carsten
>>
>>_______________________________________________
>>6lowpan mailing list
>>[e-mail]
>>https://www.ietf.org/mailman/listinfo/6lowpan
>>
>>The information contained in this message may be confidential and
>>legally protected under applicable law. The message is intended solely
>>for the addressee(s). If you are not the intended recipient, you are
>>hereby notified that any use, forwarding, dissemination, or
>>reproduction of this message is strictly prohibited and may be
>>unlawful. If you are not the intended recipient, please contact the
>>sender by return e-mail and destroy all copies of the original message.
>>
>>_______________________________________________
>>6lowpan mailing list
>>[e-mail]
>>https://www.ietf.org/mailman/listinfo/6lowpan
>
>
>The information contained in this message may be confidential and
>legally protected under applicable law. The message is intended solely
>for the addressee(s). If you are not the intended recipient, you are
>hereby notified that any use, forwarding, dissemination, or
>reproduction of this message is strictly prohibited and may be
>unlawful. If you are not the intended recipient, please contact the
>sender by return e-mail and destroy all copies of the original message.



The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.