Subject: [6lo] IID length in draft-ietf-6lo-btle-06.txt - why64?

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 16 Jan 2015 10:34:11 +0100

Hello,

I wonder why is the length of the IID in draft-ietf-6lo-btle-06.txt set 
to 64 since the BTLE MAC address is just 48bit?

Is there a problem if we set the IID length to 48?

Because if we do, then we may have an advantage in using longer than 64 
prefix lengths in the BTLE subnet - e.g. /65.  This is helpful in 
networks at the very edge of the Internet - typically the prefix 
arriving from the Internet to the 6LBR is is of length 64.  With such a 
prefix arriving to the 6LBR it is practically impossible to create 
another prefix of length also 64 beyond 6LBR, in the BTLE subnet.  Hence 
we'd need a prefix length of /65 in the BTLE subnet.  But a /65 in BTLE 
is impossible if the IID is of length 64.

Let me illustrate this by way of comparison:

                          6LN
                           \              ____________
            /65 impossible  \       /64  /            \
                    6LN ---- 6LBR ----- |  Internet   |
                            /            \____________/
                           /
                          6LN

             - with IID of length 64 -

--------------------------------------------------------------

                          6LN
                           \              ____________
              /65 possible  \       /64  /            \
                    6LN ---- 6LBR ----- |  Internet   |
                            /            \____________/
                           /
                          6LN

             - with IID of length 48 -

Alex
PS:  fyi a soon-to-be-RFC on the topic draft-ietf-6man-why64-08
      "Analysis of the 64-bit Boundary in IPv6 Addressing"

---

From: <[email-masked]>
Date: Fri, 16 Jan 2015 11:47:18 +0000

Hi Alexandru,

You describe a general problem which I don't think should be solved as part of IPv6 over BLE work.

> Is there a problem if we set the IID length to 48?

There is. I immediately see three:

1)
RFC7421 section 4.3.1 shows that all those stacks IGNORE option with other than 64-bit Prefix, right? I don't think embedded stacks support other than 64 bit IIDs either => Lack of support on existing stacks => would require even more new implementation effort => risks & deployment delays.

RFC7421 section 4.1 shows a long set of standards that mandate 64, and are still successful. => No proven working code for other lengths of IID => risks & deployment delays.

RFC7421 "makes no proposal for a change to the IID length." - so there's no RFC that "mandates variable/non-64 length IID for old and/or new IPv6 over Foo" => No requirement even from IETF.

2)
Standardization of a link layer that support longer than /64 bit prefixes causes stacks (at least on devices wishing to support that type of link layer) to be modified to support longer than /64 bit prefixes. It is not a big leap then to start requiring other type of link layers to support longer prefixes as well (now that stacks would already have support:-). That could result e.g. network operators to start providing /88 (as 48 bits for IID is enough..) for edge devices (that would happen to be 6LBRs). Hence after a while we'd end up to same problem but now with 48 bit IIDs instead of 64.

3)
Random IIDs provide less privacy (due 16 bits less to use for randomization).

Hence I think the right answer to the problem you mention is deployment and use of DHCPv6 PD. I don't think changing of IID length is the right answer for operators not willing to support DHCPv6 PD.

Teemu

P.S. Shorter IID might help in header compression, as longer part of the address used could be covered by compression context prefix

-----Original Message-----
From: 6lo [mailto:[email-masked]] On Behalf Of ext Alexandru Petrescu
Sent: 16. tammikuuta 2015 11:34
To: [email-masked]
Subject: [6lo] IID length in draft-ietf-6lo-btle-06.txt - why64?

Hello,

I wonder why is the length of the IID in draft-ietf-6lo-btle-06.txt set to 64 since the BTLE MAC address is just 48bit?

Because if we do, then we may have an advantage in using longer than 64 prefix lengths in the BTLE subnet - e.g. /65.  This is helpful in networks at the very edge of the Internet - typically the prefix arriving from the Internet to the 6LBR is is of length 64.  With such a prefix arriving to the 6LBR it is practically impossible to create another prefix of length also 64 beyond 6LBR, in the BTLE subnet.  Hence we'd need a prefix length of /65 in the BTLE subnet.  But a /65 in BTLE is impossible if the IID is of length 64.

                          6LN
                           \              ____________
            /65 impossible  \       /64  /            \

                          6LN
                           \              ____________
              /65 possible  \       /64  /            \

Alex

_______________________________________________
6lo mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/6lo

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 16 Jan 2015 17:58:42 +0100

Hi Teemu,

Le 16/01/2015 12:47, [email-masked] a écrit :
> 1) RFC7421 section 4.3.1 shows that all those stacks IGNORE option
> with other than 64-bit Prefix, right?

Some stacks ignore them, others complain more loudly.

> I don't think embedded stacks support other than 64 bit IIDs either
> => Lack of support on existing stacks => would require even more new
> implementation effort => risks & deployment delays.

The implementation effort would be necessary indeed - bug correction.

> RFC7421 section 4.1 shows a long set of standards that mandate 64,
> and are still successful. => No proven working code for other
> lengths of IID => risks & deployment delays.

I agree.

> RFC7421 "makes no proposal for a change to the IID length." - so
> there's no RFC that "mandates variable/non-64 length IID for old
> and/or new IPv6 over Foo" => No requirement even from IETF.

Right, that RFC does not make any requirement.

> 2) Standardization of a link layer that support longer than /64 bit
> prefixes causes stacks (at least on devices wishing to support that
> type of link layer) to be modified to support longer than /64 bit
> prefixes. It is not a big leap then to start requiring other type of
> link layers to support longer prefixes as well (now that stacks
> would already have support:-). That could result e.g. network
> operators to start providing /88 (as 48 bits for IID is enough..) for
> edge devices (that would happen to be 6LBRs). Hence after a while
> we'd end up to same problem but now with 48 bit IIDs instead of 64.

I agree.  In that future we could come up with shorter than 48bit length 
IIDs (i.e. 16bit, or even just one bit, like in IPv4).

But today? The cellular operators currently do not accept that there are 
several devices behind one smartphone; cellular operators only provide 
/64 to the smartphone because they know there is this 64bit limit.

In the past? IPv4 CIDR was invented and stacks had to be modified to 
accommodate IPv4 "IIDs" of length 1.

> 3) Random IIDs provide less privacy (due 16 bits less to use for
> randomization).

I agree, shorter IIDs is less crypto capability.  But there may be other 
methods for privacy than crypting the IPv6 addresses.

> Hence I think the right answer to the problem you mention is
> deployment and use of DHCPv6 PD. I don't think changing of IID
> length is the right answer for operators not willing to support
> DHCPv6 PD.

The IPv6-over-BTLE document may not work with current cellular networks, 
right?

Alex

>
> Teemu
>
> P.S. Shorter IID might help in header compression, as longer part of
> the address used could be covered by compression context prefix
>
>
> -----Original Message----- From: 6lo [mailto:[email-masked]] On
> Behalf Of ext Alexandru Petrescu Sent: 16. tammikuuta 2015 11:34 To:
> [email-masked] Subject: [6lo] IID length in draft-ietf-6lo-btle-06.txt
> - why64?
>
> Hello,
>
> I wonder why is the length of the IID in draft-ietf-6lo-btle-06.txt
> set to 64 since the BTLE MAC address is just 48bit?
>
> Because if we do, then we may have an advantage in using longer than
> 64 prefix lengths in the BTLE subnet - e.g. /65.  This is helpful in
> arriving from the Internet to the 6LBR is is of length 64.  With such
> a prefix arriving to the 6LBR it is practically impossible to create
> another prefix of length also 64 beyond 6LBR, in the BTLE subnet.
> Hence we'd need a prefix length of /65 in the BTLE subnet.  But a /65
> in BTLE is impossible if the IID is of length 64.
>
> 6LN \              ____________ /65 impossible  \       /64  /
> \ 6LN ---- 6LBR ----- |  Internet   | /            \____________/ /
> 6LN
>
> 6LN \              ____________ /65 possible  \       /64  /
> \ 6LN ---- 6LBR ----- |  Internet   | /            \____________/ /
> 6LN
>
> Alex PS:  fyi a soon-to-be-RFC on the topic draft-ietf-6man-why64-08
> _______________________________________________ 6lo mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/6lo
>
>

---

From: Sten Carlsen <[email-masked]>
Date: Fri, 16 Jan 2015 18:37:14 +0100

Just one comment below:

> /64 to the smartphone because they know there is this 64bit limit.
Maybe in your country, in my part of the world, they advertise that you
can feed the whole family from one wireless account. They will even
provide a router to do that. At least in IPv4, so I can not imagine that
changing in IPv6?

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

       "MALE BOVINE MANURE!!!"

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 16 Jan 2015 18:55:24 +0100

Le 16/01/2015 18:37, Sten Carlsen a écrit :
>> I agree.  In that future we could come up with shorter than 48bit
>> length IIDs (i.e. 16bit, or even just one bit, like in IPv4).
>>
>> But today? The cellular operators currently do not accept that
>> there are several devices behind one smartphone; cellular
>> operators only provide /64 to the smartphone because they know
>> there is this 64bit limit.
>
> Maybe in your country, in my part of the world, they advertise that
> you can feed the whole family from one wireless account.

Good :-)

> They will even provide a router to do that. At least in IPv4,

YEs, in my part of the world too they sell these cellular wireless
routers with some success.  In IPv4 they do NAT.

> so I can not imagine that changing in IPv6?

These cellular/wifi dont do IPv6.

Alex

>>
>> In the past? IPv4 CIDR was invented and stacks had to be modified
>> to accommodate IPv4 "IIDs" of length 1.
>>
>
>

---

From: Sten Carlsen <[email-masked]>
Date: Fri, 16 Jan 2015 19:09:50 +0100

> These cellular/wifi dont do IPv6.
YET.

-- 
Best regards

Sten Carlsen

       "MALE BOVINE MANURE!!!"

---

From: <[email-masked]>
Date: Fri, 16 Jan 2015 18:22:41 +0000

Alexandru,

>> deployment and use of DHCPv6 PD. I don't think changing of IID length 
>> is the right answer for operators not willing to support
>> DHCPv6 PD.
>The IPv6-over-BTLE document may not work with current cellular networks, right?

No surprise, after all, it is specification for IPv6 over BLE;-)

But more seriously, 3GPP uplink is "just" one of many for possible uplink technologies for IPv6 BLE deployments. Another one, for example, is cable connection on fixed deployments, such as on homes. And I recall, home IPv6 connections (where available) are not generally limited to /64. 

Furthermore, as I said in my previous email, "you describe a general problem which I don't think should be solved as part of IPv6 over BLE work". 

What I mean with that is that the problem you raised here is well known and by no means related or limited to Bluetooth LE. The same problem is already present in 3GPP-WiFi tethering scenario, as you well know (but more generally in tethering 3GPP access to any other LAN technology there is). The right solution is to deploy DHCPv6 (with prefix exclude option, of course:) and meanwhile use solutions such as RFC 7278. The wrong solution would be to hack IPv6 on other access technologies just because 3GPP operator(s) don't provide enough prefixes.

Best regards,

Teemu

P.S. As of today, for the 3GPP scenario, I'd be more concerned about having zero IPv6 prefix (==IPv4-only cellular connection:)

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 17 Jan 2015 20:18:03 +0100

> No surprise, after all, it is specification for IPv6 over BLE;-)

Right, it is BTLE.  But a BTLE network disconnected from the Internet
wouldnt make much sense.  It wouldn't need to use IP at all.

> But more seriously, 3GPP uplink is "just" one of many for possible
> uplink technologies for IPv6 BLE deployments.

Yes.

> Another one, for example, is cable connection on fixed deployments,
> such as on homes. And I recall, home IPv6 connections (where
> available) are not generally limited to /64.

YEs, there are many DSL connections which offer /56.

But, when using it with a BTLE network which needs /64 one has to 
perform a routing operation on the DSL box for that /64.  Currently 
there is no automated mechanism to achieve it.  DSL operators do not 
support DHCPv6 PD for devices within homenet, only for the DSL box.

As such, if one assumes the BTLE network to connect to such DSL network 
one  has to tell how is the /64 routed to the BTLE network - maybe 
stating that today people can only do manual static routes on the DSL box.

On another hand, if the IP-BTLE spec said that the IID is 48, then the 
IP-BTLE spec could specify what happens _only_ on the 6LBR (not on the 
DSL box).

> Furthermore, as I said in my previous email, "you describe a general
> problem which I don't think should be solved as part of IPv6 over
> BLE work".

I agree, the problem applies to other non-BTLE networks.

> What I mean with that is that the problem you raised here is well
> known and by no means related or limited to Bluetooth LE. The same
> problem is already present in 3GPP-WiFi tethering scenario, as you
> well know (but more generally in tethering 3GPP access to any other
> LAN technology there is). The right solution is to deploy DHCPv6
> (with prefix exclude option, of course:) and meanwhile use solutions
> such as RFC 7278. The wrong solution would be to hack IPv6 on other
> access technologies just because 3GPP operator(s) don't provide
> enough prefixes.

I agree.

But a IP-BTLE spec which freezes the IID length to 64 may represent an 
obstacle to deployment, not a help to deployment.

(until the DHCPv6-PD deployment situation changes).

Alex

>
> Best regards,
>
> Teemu
>
> P.S. As of today, for the 3GPP scenario, I'd be more concerned about
> having zero IPv6 prefix (==IPv4-only cellular connection:)
>
>

---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
http://www.avast.com

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 17 Jan 2015 20:20:55 +0100

>> These cellular/wifi dont do IPv6.

There are cellular operators who do IPv6, but who do not do IPv6 on 
their cellular/wifi devices.

I cant take this as a hint of preparing to do IPv6 on their 
cellular/wifi devices.

Alex

---

---

From: <[email-masked]>
Date: Sun, 18 Jan 2015 09:14:56 +0000

Alexandru, I hear your argument, but in my opinion the 64 bit IID continues to be the preferred way forward.

Teemu

-----Original Message-----
From: ext Alexandru Petrescu [mailto:[email-masked]] 
Sent: 17. tammikuuta 2015 21:18
To: Savolainen Teemu (Nokia-TECH/Tampere)
Cc: [email-masked]
Subject: Re: [6lo] IID length in draft-ietf-6lo-btle-06.txt - why64?

> No surprise, after all, it is specification for IPv6 over BLE;-)

Right, it is BTLE.  But a BTLE network disconnected from the Internet wouldnt make much sense.  It wouldn't need to use IP at all.

Yes.

But, when using it with a BTLE network which needs /64 one has to perform a routing operation on the DSL box for that /64.  Currently there is no automated mechanism to achieve it.  DSL operators do not support DHCPv6 PD for devices within homenet, only for the DSL box.

As such, if one assumes the BTLE network to connect to such DSL network one  has to tell how is the /64 routed to the BTLE network - maybe stating that today people can only do manual static routes on the DSL box.

On another hand, if the IP-BTLE spec said that the IID is 48, then the IP-BTLE spec could specify what happens _only_ on the 6LBR (not on the DSL box).

> problem which I don't think should be solved as part of IPv6 over BLE 
> work".

> LAN technology there is). The right solution is to deploy DHCPv6 (with 
> prefix exclude option, of course:) and meanwhile use solutions such as 
> RFC 7278. The wrong solution would be to hack IPv6 on other access 
> technologies just because 3GPP operator(s) don't provide enough 
> prefixes.

I agree.

But a IP-BTLE spec which freezes the IID length to 64 may represent an obstacle to deployment, not a help to deployment.

Alex

---

---

From: Ole Troan <[email-masked]>
Date: Mon, 19 Jan 2015 08:45:55 +0100

> Alexandru, I hear your argument, but in my opinion the 64 bit IID continues to be the preferred way forward.

indeed. while we have HNCP and DHCP PD, it might be time to look at the problem of extending a network again. a second look at MLSR perhaps? that's not a problem that should be solved in an IP over foo document though.

cheers,
Ole

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 19 Jan 2015 11:42:02 +0100

Le 19/01/2015 08:45, Ole Troan a écrit :
>> Alexandru, I hear your argument, but in my opinion the 64 bit IID
>> continues to be the preferred way forward.
>
> indeed. while we have HNCP and DHCP PD, it might be time to look at
> the problem of extending a network again. a second look at MLSR
> perhaps? that's not a problem that should be solved in an IP over foo
> document though.

But is an IP-over-foo document having a right to _freeze_ an Interface 
ID length?

I thought an IP address was an opaque value?

Alex

>
> cheers, Ole
>
>> -----Original Message----- From: ext Alexandru Petrescu
>> [mailto:[email-masked]] Sent: 17. tammikuuta 2015
>> 21:18 To: Savolainen Teemu (Nokia-TECH/Tampere) Cc: [email-masked]
>>>>> deployment and use of DHCPv6 PD. I don't think changing of
>>>>> IID length is the right answer for operators not willing to
>>>>> support DHCPv6 PD.
>> Right, it is BTLE.  But a BTLE network disconnected from the
>> Internet wouldnt make much sense.  It wouldn't need to use IP at
>> all.
>>
>>> But more seriously, 3GPP uplink is "just" one of many for
>>> possible uplink technologies for IPv6 BLE deployments.
>>
>> Yes.
>>
>>> Another one, for example, is cable connection on fixed
>>> deployments, such as on homes. And I recall, home IPv6
>>> connections (where available) are not generally limited to /64.
>>
>> there is no automated mechanism to achieve it.  DSL operators do
>> not support DHCPv6 PD for devices within homenet, only for the DSL
>> box.
>>
>> As such, if one assumes the BTLE network to connect to such DSL
>> network one  has to tell how is the /64 routed to the BTLE network
>> - maybe stating that today people can only do manual static routes
>> on the DSL box.
>>
>> On another hand, if the IP-BTLE spec said that the IID is 48, then
>> the IP-BTLE spec could specify what happens _only_ on the 6LBR (not
>> on the DSL box).
>>
>>> Furthermore, as I said in my previous email, "you describe a
>>> general problem which I don't think should be solved as part of
>>> IPv6 over BLE work".
>>
>>> What I mean with that is that the problem you raised here is
>>> well known and by no means related or limited to Bluetooth LE.
>>> The same problem is already present in 3GPP-WiFi tethering
>>> scenario, as you well know (but more generally in tethering 3GPP
>>> access to any other LAN technology there is). The right solution
>>> is to deploy DHCPv6 (with prefix exclude option, of course:) and
>>> meanwhile use solutions such as RFC 7278. The wrong solution
>>> would be to hack IPv6 on other access technologies just because
>>> 3GPP operator(s) don't provide enough prefixes.
>>
>> I agree.
>>
>> But a IP-BTLE spec which freezes the IID length to 64 may represent
>> an obstacle to deployment, not a help to deployment.
>>
>>> P.S. As of today, for the 3GPP scenario, I'd be more concerned
>>> about having zero IPv6 prefix (==IPv4-only cellular connection:)
>>>
>>>
>>
>>
>> --- L'absence de virus dans ce courrier électronique a été vérifiée
>> par le logiciel antivirus Avast. http://www.avast.com
>>

---

From: Ole Troan <[email-masked]>
Date: Mon, 19 Jan 2015 11:50:36 +0100

Alex,

> But is an IP-over-foo document having a right to _freeze_ an Interface ID length?

absolutely. just like the other IP over foo documents do. e.g. rfc2464. see the complete list in rfc7421.

> I thought an IP address was an opaque value?

yes.

cheers,
Ole

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 19 Jan 2015 11:54:55 +0100

Le 19/01/2015 11:50, Ole Troan a écrit :
> Alex,
>
>>>> Alexandru, I hear your argument, but in my opinion the 64 bit
>>>> IID continues to be the preferred way forward.
>>>
>>> indeed. while we have HNCP and DHCP PD, it might be time to look
>>> at the problem of extending a network again. a second look at
>>> MLSR perhaps? that's not a problem that should be solved in an IP
>>> over foo document though.
>>
> absolutely. just like the other IP over foo documents do. e.g.
> rfc2464. see the complete list in rfc7421.

Yes, but should we continue that way?

Why can't we just say that an Interface ID has a variable length?

>> I thought an IP address was an opaque value?

But it is not opaque as long as we say that the last 64bits are an 
Interface ID, which itself has a frozen length.

Alex

>>>> [mailto:[email-masked]] Sent: 17. tammikuuta
>>>> 2015 21:18 To: Savolainen Teemu (Nokia-TECH/Tampere) Cc:
>>>> [email-masked] Subject: Re: [6lo] IID length in
>>>> draft-ietf-6lo-btle-06.txt - why64?
>>>>
>>>>>>> Hence I think the right answer to the problem you mention
>>>>>>> is deployment and use of DHCPv6 PD. I don't think
>>>>>>> changing of IID length is the right answer for operators
>>>>>>> not willing to support DHCPv6 PD.
>>>> Internet wouldnt make much sense.  It wouldn't need to use IP
>>>> at all.
>>>>
>>>> But, when using it with a BTLE network which needs /64 one has
>>>> to perform a routing operation on the DSL box for that /64.
>>>> Currently there is no automated mechanism to achieve it.  DSL
>>>> operators do not support DHCPv6 PD for devices within homenet,
>>>> only for the DSL box.
>>>>
>>>> As such, if one assumes the BTLE network to connect to such
>>>> DSL network one  has to tell how is the /64 routed to the BTLE
>>>> network - maybe stating that today people can only do manual
>>>> static routes on the DSL box.
>>>>
>>>> On another hand, if the IP-BTLE spec said that the IID is 48,
>>>> then the IP-BTLE spec could specify what happens _only_ on the
>>>> 6LBR (not on the DSL box).
>>>>
>>>>> general problem which I don't think should be solved as part
>>>>> of IPv6 over BLE work".
>>>>
>>>>> well known and by no means related or limited to Bluetooth
>>>>> LE. The same problem is already present in 3GPP-WiFi
>>>>> tethering scenario, as you well know (but more generally in
>>>>> tethering 3GPP access to any other LAN technology there is).
>>>>> The right solution is to deploy DHCPv6 (with prefix exclude
>>>>> option, of course:) and meanwhile use solutions such as RFC
>>>>> 7278. The wrong solution would be to hack IPv6 on other
>>>>> access technologies just because 3GPP operator(s) don't
>>>>> provide enough prefixes.
>>>>
>>>> I agree.
>>>>
>>>> But a IP-BTLE spec which freezes the IID length to 64 may
>>>> represent an obstacle to deployment, not a help to deployment.
>>>>
>>>>> P.S. As of today, for the 3GPP scenario, I'd be more
>>>>> concerned about having zero IPv6 prefix (==IPv4-only cellular
>>>>> connection:)
>>>>>
>>>>>
>>>>
>>>>
>>>> --- L'absence de virus dans ce courrier électronique a été
>>>> vérifiée par le logiciel antivirus Avast. http://www.avast.com
>>>>
>>>> _______________________________________________ 6lo mailing
>>>> list [email-masked] https://www.ietf.org/mailman/listinfo/6lo
>>>
>>>
>>
>
>
>

---

From: Ole Troan <[email-masked]>
Date: Mon, 19 Jan 2015 12:10:35 +0100

Alex,

> Why can't we just say that an Interface ID has a variable length?

regardless of that, the place to change the IPv6 addressing model isn't in this document.

> But it is not opaque as long as we say that the last 64bits are an Interface ID, which itself has a frozen length.

depends on the perspective.

cheers,
Ole

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 19 Jan 2015 13:07:16 +0100

Le 19/01/2015 12:10, Ole Troan a écrit :
> Alex,
>
>>>>>> Alexandru, I hear your argument, but in my opinion the 64
>>>>>> bit IID continues to be the preferred way forward.
>>>>>
>>>>> indeed. while we have HNCP and DHCP PD, it might be time to
>>>>> look at the problem of extending a network again. a second
>>>>> look at MLSR perhaps? that's not a problem that should be
>>>>> solved in an IP over foo document though.
>>>>

My remark is not trying to change the IPv6 addressing model in general. 
  This remark is about IP-over-BTLE for SLAAC; and I have same remark to 
the IP-over-NFC document as well.

This IPv6-over-BTLE document states that the IID length in BTLE is 64bit 
even though the BTLE address is 48bit, and SLAAC can work with 48bit IIDs.

This IPv6-over-BTLE document states that the constant 0xfffe must be 
inserted even though no receiver interprets this value.

I remark that there is no technical reason to do so.

Alex

>>>>>>>>> Hence I think the right answer to the problem you
>>>>>>>>> mention is deployment and use of DHCPv6 PD. I don't
>>>>>>>>> think changing of IID length is the right answer for
>>>>>>>>> operators not willing to support DHCPv6 PD.
>>>>>> Right, it is BTLE.  But a BTLE network disconnected from
>>>>>> the Internet wouldnt make much sense.  It wouldn't need to
>>>>>> use IP at all.
>>>>>>
>>>>>>> But more seriously, 3GPP uplink is "just" one of many
>>>>>>> for possible uplink technologies for IPv6 BLE
>>>>>>> deployments.
>>>>>>
>>>>>> Yes.
>>>>>>
>>>>>> But, when using it with a BTLE network which needs /64 one
>>>>>> has to perform a routing operation on the DSL box for that
>>>>>> /64. Currently there is no automated mechanism to achieve
>>>>>> it.  DSL operators do not support DHCPv6 PD for devices
>>>>>> within homenet, only for the DSL box.
>>>>>>
>>>>>> As such, if one assumes the BTLE network to connect to
>>>>>> such DSL network one  has to tell how is the /64 routed to
>>>>>> the BTLE network - maybe stating that today people can only
>>>>>> do manual static routes on the DSL box.
>>>>>>
>>>>>> On another hand, if the IP-BTLE spec said that the IID is
>>>>>> 48, then the IP-BTLE spec could specify what happens _only_
>>>>>> on the 6LBR (not on the DSL box).
>>>>>>
>>>>>>> Furthermore, as I said in my previous email, "you
>>>>>>> describe a general problem which I don't think should be
>>>>>>> solved as part of IPv6 over BLE work".
>>>>>>
>>>>>>> What I mean with that is that the problem you raised here
>>>>>>> is well known and by no means related or limited to
>>>>>>> Bluetooth LE. The same problem is already present in
>>>>>>> 3GPP-WiFi tethering scenario, as you well know (but more
>>>>>>> generally in tethering 3GPP access to any other LAN
>>>>>>> technology there is). The right solution is to deploy
>>>>>>> DHCPv6 (with prefix exclude option, of course:) and
>>>>>>> meanwhile use solutions such as RFC 7278. The wrong
>>>>>>> solution would be to hack IPv6 on other access
>>>>>>> technologies just because 3GPP operator(s) don't provide
>>>>>>> enough prefixes.
>>>>>>
>>>>>> I agree.
>>>>>>
>>>>>>> concerned about having zero IPv6 prefix (==IPv4-only
>>>>>>> cellular connection:)
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________ 6lo
>>>>>> mailing list [email-masked]

---

From: Gabriel Montenegro <[email-masked]>
Date: Mon, 19 Jan 2015 21:52:34 +0000

Hi Alex and others,

There's advantages and disadvantages.
My knee-jerk reaction with co-chair hat on is to note that evaluating this needs to  involve the 6man working group. But then I realize that we're in the enviable position of having their position stated very clearly in the brand-new RFC7421:
   
   ...However, the consensus of the IETF is that the
   benefits of keeping the length fixed at 64 bits and the practical
   difficulties of changing it outweigh the arguments for change.

Gabriel

---

From: Samita Chakrabarti <[email-masked]>
Date: Tue, 20 Jan 2015 02:37:31 +0000

I agree with Gabriel  on keeping the compliance of 64bit IID in 6lo WG .

Cheers,
-Samita

-----Original Message-----
From: 6lo [mailto:[email-masked]] On Behalf Of Gabriel Montenegro
Sent: Monday, January 19, 2015 1:53 PM
To: Alexandru Petrescu; Ole Troan
Cc: [email-masked]; [email-masked]
Subject: Re: [6lo] IID length in draft-ietf-6lo-btle-06.txt - why64?

Hi Alex and others,

Gabriel

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 20 Jan 2015 18:36:47 +0100

Hello Gabriel,

Thank you for the message.

I am not trying at changing a decision.

Please allow me an argumentation for the sake of argumentation.

That 6man RFC is INFORMATIONAL only.  During that 6man discussion some 
opinion were against the paragraph cited below.  Also, there's a v6ops 
WG item which states that the forwarding happens on netmasks up to 128 
(which would be impossible with SLAAC and IIDs of length 64) 
(draft-ietf-v6ops-cidr-prefix-00.txt).

Changing implementations may prove difficult if BTLE is used on an 
android platform which inherits the typical linux IPv6 stack.    But it 
may be easy to do on BTLE devices which uses newer and lighter IP stacks.

I dont see in the immediate any interoperability problem if the IID were 
48 in BTLE.

My last message on this, thanks.

Alex

Le 19/01/2015 22:52, Gabriel Montenegro a écrit :
> Hi Alex and others,
>
> There's advantages and disadvantages. My knee-jerk reaction with
> co-chair hat on is to note that evaluating this needs to  involve the
> 6man working group. But then I realize that we're in the enviable
> position of having their position stated very clearly in the
> brand-new RFC7421:
>
> ...However, the consensus of the IETF is that the benefits of keeping
> the length fixed at 64 bits and the practical difficulties of
> changing it outweigh the arguments for change.
>
> Gabriel
>
>