IPv6 URL Support about eddystone HOT 5 OPEN

We've discussed IPv6 and you are correct, that with a new EddyStone-URL encoding byte, we could pack it into a standard ad packet. However, keep in mind that an IP address, by itself, isn't that helpful to the user. The Physical Web scanner on the phone, for the moment, assumes the target is a web page so it fetches the title and description tags from within the markup. This allows a much better presentation of the possible choices to the user.

I'm not against putting in IPv6 numbers, I'm just saying we also need to discuss how we'd fetch the metadata that we currently expect to get from a web page. We don't expect that we'll use web pages exclusively going forward, it's just our first step.

from eddystone.

"However, keep in mind that an IP address, by itself, isn't that helpful to the user."

Absolutely. I wasn't at all implying a Eddystone meta-data over IP protocol. My only interest here is in allowing for RFC2732 Format for Literal IPv6 Addresses in URL compliant URL's to be possible.

In this ticket, the device would still have to have an HTTP stack, and would be advertising HTTP or HTTPS urls. This ticket is to get around the need for a central, stable DNS: "Many mobile phones for example have IPv6 but not a known DNS name: they should still have some option to advertise their address as a Eddystone-URL." The idea was that the Eddystone-URL being advertised would be the Literal IPv6 for a webserver: that is all.

The current software would work exactly as it does- attempting a Web Manifest/page scrape process as the current Physical Web scanner does. The only thing I'm proposing is the capability for the webserver to advertise itself without a DNS name and without an IPv4 address. There's enough bytes on the line to permit IPv6 accessible webservers to be reached, but not via an ASCII encoding- http://[2607:f8b0:4002:c06::71]/ (an IPv6 Literal for www.google.com atm) is too big to fit without alternate accommodations. Without IPv6, there's no hope for Eddystone-URLs to be used without DNS identifying IPv6 devices, like phones or link-local devices. Please support IPv6 Addressing in Eddystone-URLs.

from eddystone.

"The idea was that the Eddystone-URL being advertised would be the Literal IPv6 for a webserver: that is all."

We are in complete agreement then.

As to how to encode them we have a few paths. If we want to fit into exiting BLE4.x ad packets we'd have to squeeze into our 18byte URL space (we are avoiding SCAN_RESP packets as it requires a connection and gets N-squared in busy public locations) This would require a new compression byte, likely one for 'http://' a as well as one for 'https://'. The following 16 bytes would be the binary IPv6 address. Unfortunately, there would be no room from any trailing paths (such as 'index.html')

The other approach (which I assume you won't like) is to wait for BLE 5.x and just encode as a string, as pointed to by RFC2732 above. The additional downside is that the payload is now twice as long (which also has battery impact. I'm assuming we won't go for this...

The one downside (for the Physical Web) is that our current approach to meta data is to offload that to a proxy service (which assumes a globally addressable web page) If the IPv6 address is that, we're fine. If on the otherhand, it isn't, it means that the scanner on the phone would have to parse the web page which is a bit processor heavy, exposes the user to finger printing, and is a bit data heavy as well (not a show stoppper but this shows why we use a proxy service for the Physical Web. Keep in mind that if you have a room full of these devices, every phone in the room would have to parse each webpage just to show a list (that the user may simply close) This also puts a much heavier burden on each device.

So we have a way forward here. I'd just like to get a few more comments and discuss this with a few more folks.

from eddystone.

@rektide Any thoughts on this? Interested in your feedback. As I said, we're happy to consider this but the downside is that we'd ONLY be able to fit the IP address. So for example:

FEDC:BA98:7654:3210:FEDC:BA98:7654:3210

could be encoded (per the spec) as

https://[FEDC:BA98:7654:3210:FEDC:BA98:7654:3210]

however, we would NOT be able to do:

https://[FEDC:BA98:7654:3210:FEDC:BA98:7654:3210]:80/index.html

as we simply wouldn't have enough room.

Most people we've talked to are willing to use URL shorteners for now. As the BLE 5.0 spec rolls out, it allows MUCH more flexibility in doing URLs. I'm curious if you feel this limited version of IPv6 addresses would be worth it? If most people want to specify ports/paths, it would be a lot of work for little gain. It would be helpful get some feedback from the community before we proceed.

from eddystone.

Sorry for missing the boat, by a couple of years.

I absolutely think a bare IPv6 address would FOR SURE be worth advertising.

Just advertising your sites IPv6 is a great start. Further, with ipv6, the address itself could very well be the identifier. Many VPS plans come with a /96 allocation or more- that's an entire IPv4 sized address space that your single server can have. The beacon could advertise a specific address that routes (redirects) to a more context-appropriate domain-named service (https://[FEDC:BA98:7654:3210:FEDC:BA98:7654:3210] -> https://yoyodyne.example.com/isle-7/overthrusters).

I would love to see ipv6 added. The above discusses some of it's routing potential. But I also think it will be critical and absolutely vital as ipv6 low powered mesh routing continues to emerge & evolve. BT5.0 will- when it finally finally finally finally starts becoming productized- be a core driver & precipitate this need.

from eddystone.