diff --git a/doc/dev/design/V6-address-support.rst b/doc/dev/design/V6-address-support.rst new file mode 100644 index 0000000000..26140c77a1 --- /dev/null +++ b/doc/dev/design/V6-address-support.rst @@ -0,0 +1,373 @@ +***************************** +V6 compatible SCION addresses +***************************** + +:Author(s): J-C HUgly +:Last updated: 2023-08-31 +:Status: **proposal** +:Discussion: `Discussions/4324`_ + + +.. _`Discussions/4324`: https://github.com/scionproto/scion/discussions/4324 +.. _`Papers/magdeburg_scitra`: https://drive.google.com/file/d/1DoG1_NbpeOVQ6alT6KGYWkBlMn8orY_C/view +.. _`Papers/ethz_ipv6_scion_viability`: https://drive.google.com/file/d/1G20A_EkRXjnSK_xyLOdeTS9_wBvGQDLB/view + +Abstract +======== +Among other IPV6 compatibility aspects we've been discussion the possibility of making +SCION addresses a special case of IPV6 address. This requires changes to the specification +of SCION addresses so it can fit in 128 bits. I have made a few informal suggestions during +the discussion. This documents proposes a concrete design for supporting a realistic +subset of those suggestions in real code. + +This includes all relevant aspects: + +* Validation/Identification: + + * "Is this V6 address a valid SCION address?" + * "Is this scion address representable as V6?" + +* Structured conversions: + + * "Turn this V6 address into a SCION address if you can." + * "Turn this SCION address into a V6 address if you can." + +* String representation: + + * "Construct a SCION address from this V6 address string." + * "Construct a SCION address from this SCION-style address string if you can." + +* Viable migration path and future growth support: + + * Configurable address structure with support for the existing V6-incompatible + structure. + * Support of existing addresses that are convertible to the new structure + (most or all should be). + * Transcoding capability to/from legacy wire format + (that's a strech goal - it might not be entirely feasible). + +Background +========== +This topic is related to other parallel initiatives: + +* A proposal to implement SCION as an IPV6 extention, which implies the use of IPV6 + addresses as SCION addresses, thus prompting this proposal. (`Discussions/4324`_) +* An experimental implementation of an IP to SCION translator, which is triggered by the use + of identifiable SCION mapped IPV6 addresses: (`Papers/magdeburg_scitra`_) +* A study of the viability of using IPV6 addresses and extension headers to represent SCION + (`Papers/ethz_ipv6_scion_viability`_) + +Currently SCION addresses are specified to be as large as as 192 bits. As a result they +are both logically and physically incompatible with IPV6 addresses. Although nothing says +that SCION has to use IPV6 addresses in order to cohabitate peacefully with IPV6, the adoption +of SCION would be greatly facilitated if applications did not need to be modified in order +to take at least some advantage from SCION connectivity. Currently, in order for an application +to make any realisitic use of SCION, it needs new code to at least: + +* Parse non-standard textual addresses (from, config files or URLs). +* Use non-standard DNS queries, with non-standard responses, from servers configured + with unusual, if legal, records. +* Access the SCION network via a dedicated API. + +Instead, what we would like is that applications can use SCION without even knowing +it, simply as a result of: + +* Parsing a normal-looking textual V6 address from a config file or URL. +* Getting a normal AAAA result from a DNS query. +* Opening a UDP/TCP connection to said address via the regular socket API. This would imply + the existence of SCION-aware code below the socket API that: + + * Recognizes SCION addresses and handles the traffic accordingly. + * Performs some default route selection on behalf of the oblivious application. + +This proposal does not cover the last topic. However resolving the first two is a +necessary condition to resolving the last one, since an unmodified application has the +INET4 or INET6 address family assumption wired in its code. + +Nevertheless, this objective implies that SCION addresses be distinguishable from non-SCION, +without any additional hint. This creates another constraint on the present design: a valid +SCION addresses must never be bitwise identical to a non-SCION address. Therefore, SCION +addresses must occupy their own, properly reserved, portion of the IPV6 address space. +Therefore they must not just be IPV6-like addresses, they must **be** IPV6 addresses. + +This constraint comes with a silver-lining though. Currently, SCION addresses are very large +because they include a complete IPV6 address as a way to designate the destination host within +the destination AS. If SCION addresses are real IPV6 addresses, there is no need to embbed +the destination host's IPV6 address in its SCION address; they are one and the same. This means +that we "only" need to fit the ISD-AS portion (64 bits) of a SCION address into a V6 address +(128 bits). This may seem like a trivial task; in reality we have to sacrifice some things. + +Here are the constraints: + +* RFC4291 insists on the 64 LSbits to be available to contain a NIC number. +* RFC6890 Instructs IANA to reserve 2001::/23 for experimental protocols, which they allocate + in blocks of /29. Many of those are available and probably easy to get. + (https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml) +* RFC3587 reminds that IANA does not allocate addresses outside the 2000::/3 range + (https://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml). + However it is not forbidden from doing so and there's still plenty of space + (e.g. 2d00:0000::/8 is not assigned and nothing is after that). + +So, we have to fit ISD-AS, currently specified as 64 bits, into anywhere between +36 and 56 bits under realistic conditions. We could conceivably have 61 bits if +IANA could be persuaded to dedicate an entire /3 block to SCION but that's not going +to happen until SCION becomes the dominant internet protocol. So we probably shouldn't +lead with that. + +Getting a pair of /29 blocks is likely easy with the following caveats: + +* It is meant for experimental protocols, so typically temporary. IANA will want to + set an end date. If do that we have to plan on moving within a few years. +* It gives us only 36 bits; another reason to plan on moving. + +Getting a /8 block is probably feasible, especially if we have an IETF sponsor. That leaves +us 56 bits, which is quite enough unless SCION is successful beyond belief, in which case +it will make sense to ask for a larger block and we'll get it. + +If we ever get a /3 block, we'll have to move as the price to get more bits for ISD-AS numbers. +We can't count on getting it today, so we just need to be able to move. + +So, it seems like explicitly supporting changes in prefix and address structure is a good +investment that will make it easier for us to move several times. + +Proposal +======== + +Address structure roadmap +------------------------- + +* Near-term (1 or 2 years): + Get a /28 block. Cram ISD-AS into 36 bits. +* Mid-term (~10 years, depending on adoption): + Get a /8 block. Expand ISD-AS to 56 bits. +* Long-term (if and when SCION becomes huge): + Get a /3 block. Expand ISD-AS to 61 bits. +* In your wildest dreams: + IPV6 is deprecated in favor of SCION. ISD-AS expand to 64 bits, + with the exception of some blocks reserved for legacy V6 and special purpose. + +Address structure evolution +--------------------------- + +* 36 bits ISD-AS: + + * ISD is currently defined as a 16 bits field with only 12 bits + allowed to be non-zero. The rest is specified as reserved. So, 12 bits ought + to be enough for as long as we refuse to change the spec. + * AS is currently defined as a 48 bit field but only the following is + allowed: + + * One 32 bits-wide block for IP ASNs. + * One 32 bits-wide block for pure SCION ASNs. + * One 16 bits-wide block for examples. + * One 24 bits-wide block for test deployments. + + The two different ASNs blocks exist so that IP ASNs can be grand-fathered + into SCION while non IP ASNs can be given a SCION ASN number without + coliding with the grand-fathered numbers. However, IP ASNs only use + 19 bits today (https://www.iana.org/assignments/as-numbers/as-numbers.xhtml). + The rate of allocation is about linear at a rate of ~6K/Y, so it won't + even double over the next 20 years. + + We need 1 bit to maintain our pure-scion/grandfathered spaces. + + If we don't want to retain our examples and private numbers without complications, + we add one bit to set aside the space for them. + + That's a total of 21 bits. Add one bit to cover for the growths of the next 20 years: + that's 22. + * Therefore, strictly speaking we only **need** 34 bits for the next 20 years. Since + we have 36 available, we can even be wasteful and throw two extra bit to the + ISD number. Why the ISD? That's because at 14 bits it is less likely to require + future expansion. That way, we might avoid having to change it any time soon. + The AS number, on the other hand, is likely to need future expansion anyway. + +* Growing into the bright future; 56-bits ISD-AS: + + * The AS number expands to 42 bits (unless my earlier prediction was wrong + and we need to grow ISD). + * If we were smart about the layout and put the AS number on the left side, we can + grow the field in-place; so increasing the permissible whidth without moving + anything. Chances are it'll make the migration easier. Of course, if we have + to change the ISD width too, then we loose that benefit. Oh well. + * The growth comes with a change of address prefix, so, the code can tell how + to read and write addresses. If we did our job right, this is entirely contained + in header and address code that already knows how to do that. + +* The same pattern coutinues with a /3 block: + + * For what it's worth, the ASN number can grow to 47 bits (not 48... too bad). + +* SCION has taken over the internet: + + * We can finally expand ISD-AS to its glorious initial specification (at the + expanse of being forced to move the boundary between the two; that's a good + problem to have, I guess). + +Configuration +------------- + +The relative ease of performing these transitions is predicated on having code +already in-place to manipulate SCION addresses and the ISD-AS fields in headers +(if/when we use the new representation on the wire) according to the applicable +address structure. This code would need to apply the +bit widths and offsets outlined in the handfull of schemes described in +`Address structure evolution`_. Since battle plans rarely survive the first +encounter with the ennemy, it would be wise to make some details configurable, +especially since some of those are outright unknown, for example the prefixes that +IANA would grant us. + +The following scheme is proposed: + +A small number of valid address format recipes are specified in the form of +a tuple: (IPV6-prefix, ASN-width, ISD-width, Host-width) where: + +* IPV6-prefix: + A prefix in the form v6-addr-fragment/width, for example "2001:40::/28" + which indicates that the rest of the parameters describe the encoding of + a SCION addresses in that block. +* ASN-width: + The number of bits used to represent ASN. +* ISD-width: + The number of bits used to represent ISD. +* HOST-width: + The number of bits used to uniquely identify the destination host within the + destination ISD-AS. + +The existence of one such a recipe indicates that SCION addresses of the +given ASN and ISD widths must be encoded as IPV6 addresses of the given block, +and that IPV6 addresses in that block must be decoded into SCION addresses +according to the given widths. There can be multiple valid recipes, as +explained in the section `Migration between IPV6 representations`_ + +The existence of multiple applicable formats is necessary to support migration +periods during which two different blocks of V6 addresses are assigned and not +every host has been updated. An additional configuration item describes which +recipe to preferably follow when encoding SCION addresses into V6 addresses. +The preference applies to addresses that *can* be represented according to that +recipe. Since we would only carry out address growth, it should be expected that +all existing addresses can be represented in the new scheme, but out of precaution, +we should be able to perform downgrades too. + +These recipes would direct the operations of the following code (non-exhaustive): + +* Convert a binary V6 address into a componentized SCION address structure. +* Convert a componentized SCION address into a V6 address structure, +* Validate that a V6 address is convertible to a SCION address (i.e. it is in + a SCION block). +* Validate that a componentized SCION address is convertible to a V6 address (i.e. + the bit width are compatible with one of the allowed recipes). +* Shortcut methods to parse SCION addresses from, or print then to, V6 textual + representations. +* Shortcut methods to parse V6 addresses from, or print then to, SCION textual + representations. + +Migration between IPV6 representations +-------------------------------------- + +A migration from one address scheme to the next would occur in three phases: + +* Phase 1: + Between 0 and 100% of hosts have received the new recipe config. + Every host continues encoding SCION addresses according to the old scheme but + is already able to decode either, which never happens. +* Phase 2: + 100% of hosts have received the new config. + Between 0 and 100% of hosts have received the new preference config and thus + encode addresses in the new block with the new scheme. + All can decode. +* Phase 3: + 100% of hosts use the new scheme. + Between 0 and 100% of the hosts have received a new config lacking the old scheme. + It is alredy safe to create addresses that do not fit in the old scheme. + +Interrestingly, a SCION address (in its component form) does not need to carry +the IPV6 range to which it belongs because both ranges are valid during transitions +and the only valid one is known by config otherwise. There is one caveat, though. +The destination router must use the one that the destination host is using. This +could cause some difficulties that deserve closer examination. + +Rationale +========= + +Alternatives considered (regarding hidding SCION-specifcs from apps): + +* Do Nothing: + + * SCION can only be used via especially crafted applications or the SCION gateway. + * The gateway is inherently limitted by the IP-SCION address mapping. If all of SCION + has to be used through it, then it is pointless. + * Are we planning on providing replacement for all the applications and libraries + using internet today? Is someone else? + +* Map IPV6 addresses to SCION ISD-AS downstream from the application: + That's only a temporary patch see the same issue with the gateway. + +Compatibility +============= + +Migration from current addressing +--------------------------------- + +The address format described in this proposal needs not, at first, apply to the wire fomat. +The main objective is for applications to be able to designate SCION hosts by way of a +regular IPV6 address. This means that the only decoding and encoding taking place must be +at the boundary of the SCION API. An application would be allowed to use new methods that +accept IPV6 addresses in-lieu of SCION addresses, and chose a default route implicitly. + +However, the SCION/IPV6 address encoding is predicated on the fact that the the full IPV6 +address of the destination host is identical to its SCION address; this means that: + +* When the new schema is in use, a destination address supplied by the application + is partially redundantly encoded as the HOST portion of the wire format SCION address. +* That address is a real IPV6 address, reachable by the destination border router. + +Until we reach the point where SCION routing is part of the normal network stack (and therefore +SCION addresses need to be distinguished from other V6 addresses) we can get away with using +arbitrary IPV6 addresses in the unique local range. After that, we need to start using real +assigned IPV6 addresses from a block supplied by IANA. + +Migration of the wire format +---------------------------- + +Eventually we will want to update the wire format to replace the current ISD-AS-128bitHOST +addresses with plain V6 addresses. A possible migration plan would be: + +1. Keep the address representation in code unchanged (ie. ISD-AS-HOST components, full + sized), and add the proper, parametrized, encoding/decoding layer between the code and + the wire format. That code follows the same configuration as that used at the API, with + one additional option to emit the legacy wire format entirely unchanged. +2. Between 0 and 100% of hosts can process the new format but emit the legacy format. +3. 100% can process the new format. Between 0 and 100% of host are configured to emit the + new format. +4. 100% of hosts use the new format. The legacy code can be deleted when convenient. + +It might prove helpful to extend the internal (componentized) address representation to +include the IPV6 prefix that is part of the native V6 representation. + +Implementation +============== + +(This section, is not finished - just an intro). + +Considering only the transition to using V6 addresses at the API: + +The thing currently most ressembling a SCION API is the snet package. The snet API, as it +currently is does not allow the use of addresses as opaque entities. The application is +expected to openly manipulate address components, find a route, and even connect to the +border router by itself. Under these conditions it not even possible to initiate the +transition to V6 addresses for our own client code (i.e. the control server, ping, others?). + +So, to make that possible we must first give our application some API that allows them +to treat an address as just that: a bunch of random bits plus, may be a port; something +equivalent to :code:`bind([addr])`, :code:`connect(addr [,routespec])`, or +:code:`sendto(addr, stuff, [,routespec])`, where :code:`addr` does not need to include +the next hop and where routespec is entirely optional. + +Once we have that, we can start enabling the use of V6 addresses as the addr argument. + +The netsec tree also offers a number of SCION-enabled apps. Those rely on "pan", a custom +API-like layer. It would be good to try and converge pan and the new API contemplated +above, so that eventually, these SCION-enabled apps are able to use plain IPV6 addresses +too. + diff --git a/doc/dev/design/index.rst b/doc/dev/design/index.rst index a77b15dbda..e5213a3b21 100644 --- a/doc/dev/design/index.rst +++ b/doc/dev/design/index.rst @@ -56,6 +56,7 @@ Postponed :maxdepth: 1 scmp-authentication + V6-address-support .. _design-docs-active: