Using URL! for an IPv6 Type

Development Datatypes
1

TUPLE! is now generalized, and can be mixed with paths, which I think is a good direction. It's also encouraging that it is mostly compatible with the previous kind of tuple.

However, those who think tuples were primarily for representing IP addresses will note that this doesn't really help you with representing IPv6 addresses.

I was closing some old rebol-issues and noticed there was a suggestion from earl of tackling this via the URL! type.

I thought I would link to that discussion and the points it raises:

Revisit, refactor or rename tuple! · Issue #1976 · metaeducation/rebol-issues · GitHub

One of the points is that URL!s aren't checked for validity, so it doesn't have the "rigor" that a notational IPV6! datatype might have. Which may displease some people, as not being much better than a string.

In any case, I'm closing the original issue itself, as I feel the broad issue of TUPLE!s is solved. But wanted something to come up here if a search were done on "IPv6".

2

So libuv is a modern library that lives in the modern world, and as such, IPv6 support is a real thing we could have.

But once we have it that means usermode code will be seeing IPv6 addresses. What are we going to do about it?

Seeing if Red has Any Ideas... no

Red's issue database they don't say anything about it, but of URL! parsing they say:

"Host is not detailed per the RFC yet. It covers IPv6 addresses, which go in square brackets, making them a non-loadable URL in Red. They can also contain colons, which makes finding the port marker more involved. The percent encoded options for brackets here are a bit of a hack as well, because Red encodes them in URLs, even in the IP literal segment.|

   ; simplified from [IPv6address | IPvFuture]|
   IP-literal:  [copy =IP-literal [[#[ | %5B] thru [#] | %5D]]]

What they're talking about is that in the internet spec, these IPv6 addresses:

FEDC:BA98:7654:3210:FEDC:BA98:7654:3210
1080:0:0:0:8:800:200C:4171
3ffe:2a00:100:7031::1
1080::8:800:200C:417A
::192.9.5.5
::FFFF:129.144.52.38
2010:836B:4179::836B:4179

would embed into URL!s like:

http://[FEDC:BA98:7654:3210:FEDC:BA98:7654:3210]:80/index.html
http://[1080:0:0:0:8:800:200C:417A]/index.html
http://[3ffe:2a00:100:7031::1]
http://[1080::8:800:200C:417A]/foo
http://[::192.9.5.5]/ipng
http://[::FFFF:129.144.52.38]:80/index.html
http://[2010:836B:4179::836B:4179]

The brackets don't seem like any particular problem for Ren-C, because we don't intend to load http://[a b c] as two separate items of a URL! and a BLOCK!, e.g. http:// [a b c].

(But we do have the question of what to do about [... http://]. I think that the idea of letting URLs do paired parentheses and paired blocks in them probably would work for most cases people would care about.)

Could we just use a BINARY!?

It might seem like we could just punt on it and use a BINARY!...saying the address is a black box. It sound like it will work, but earl writes the following in the issue I cite in the post above:

As mentioned in my first comment above, IPv6 literal syntax is in latent conflict with url! and get-word! literal syntax: a::b is a valid IPv6 address, but is currently a valid url!; ::a is a valid IPv6 address, but currently a valid get-word!. Maybe there are other conflicts as well.

Also note, that IPv6 addresses may need to be qualified with a "zone index" to be routeable. The suggested notations for a zone index is to append it to the address separated with a %. The syntax for a valid zone index itself is OS-specific. Examples: fe80::1%1, fe80::1%wlan0. (Obviously, this notation conflicts with percent encoding in url!s.) You'll have to store the zone index along with the address. For some usage scenarios you can get by with storing the zone index pre-decoded into a 32-bit integer; for other scenarios, you may have to keep the original, literal zone index specification around.

So that "zone index" is a thorn, suggesting some part of IPv6 addressing might have to be passed around as a string...

I don't know, but if anyone feels like reading up on IPv6 and thinking about it please do so. I was actually going to make a new post to bring it up, but searched and found I'd already brought it up.

Guess the point being we're now past the theory and into the practice of IPv6. So it's a more pressing issue.

2 Likes