6 ms·

Something more like UTF-8? Largely backwards compatible with old formats (ascii) while still being extensible.

johncolanduoni 9y ago
The ASCII/UTF-8 backwards compatibility relies on (a) a large subset of data fitting within the constraints of ASCII and (b) most "upstack" applications being able to handle a few garbled/unrecognized characters. How does this map to routing packets on the internet, where the IP header contains time-sensitive metadata needed for delivery and the payload is largely agnostic of the differences?
zAy0LfpBZLC8mAC 9y ago
> Something more like UTF-8? Largely backwards compatible with old formats (ascii) while still being extensible. Which would work how exactly in the case of IP? So far sounds mostly like "make it backwards compatible by making it backwards compatible".
- aexaey 9y ago
  >> Largely backwards compatible > how exactly in the case of IP? For example, introduce two special IP options that would act as "page selector" for source and destination addresses respectively. i.e. SRC: 1.1.1.1, DST: 2.2.2.2, no options -> from 1.1.1.1 to 2.2.2.2 (backwards-compatible packet, classic IPv4) SRC: 1.1.1.1, DST: 2.2.2.2, opt.X: 1.1.1, opt.Y: 2.2.2 -> from 1.1.1.1.1.1.1 to 2.2.2.2.2.2.2 (our faux-IPv6) SRC: 1.1.1.1, DST: 2.2.2.2, opt.X: 0.0.0, opt.Y: 2.2.2 -> from 1.1.1.1 to 2.2.2.2.2.2.2 ("old" address communicating with "new" address) Last example of three is impossible with IPv4/6 dichotomy, and is most important for backward compatibility here - yes, "old" IP holder needs to upgrade their software too[1], but they don't need to get a new IP address, and as a result you don't end up with two isolated "Internets", a.k.a. dual-stack. Say, for ease of processing on router, require that X and Y would appear only together, in that order, preceding other options (which is a bit of an exception as far as IP options go, but again, a backward-compatible one). Now, I'm not proposing this seriously of course, but you asked for example - here you go, a plausible, backwards-compatible "IPv4.1", if you like. [1] All major desktop OS support IPv6 for last 10 years and major mobile OS for last 7. Let's face it - software upgrade turned out (surprisingly) not to be the biggest obstacle.
  - teraflop 9y ago
    What advantage does that have over IPv6? From a backwards-compatibility perspective, it seems identical. In order for two hosts to communicate over IPv6, both ends need to have: software that supports IPv6, and the entire network path between them needs to be able to route IPv6 packets. Your proposal is functionally no different: you call the extended address field an "option", but in fact every host is required to understand it.
    - aexaey 9y ago
      I used term "options" here the way it was defined in RFC 791. [1] It's a standard way to extend IPv4 packet header. [1] https://tools.ietf.org/html/rfc791 https://tools.ietf.org/html/rfc791
  - zAy0LfpBZLC8mAC 9y ago
    > Last example of three is impossible with IPv4/6 dichotomy, and is most important for backward compatibility here - yes, "old" IP holder needs to upgrade their software too[1], but they don't need to get a new IP address, and as a result you don't end up with two isolated "Internets", a.k.a. dual-stack. 1. What would be a scenario where hosts using this mechanism could communicate where neither IPv4 nor IPv6 would work? 2. How do new internet participants get addresses under your scheme, if it only expands the number of addresses in existing allocations?
jcranmer 9y ago
The ASCII->UTF-8 transition is arguably nearly as painful as IPv4->IPv6, and it's still nowhere near complete. Switching to UTF-8 requires two major steps. The first was making software and interchange systems preserve the 8th bit (it used to be commonly used as a parity bit). For email, this was true only about the mid-to-late 90s--surprisingly recent. The second step, which is still incomplete today, is letting control mechanisms that used to speak only ASCII understand UTF-8 (or something else non-ASCII) reliably. You could only put UTF-8 in C++ or C code as of C++11/C11, for example. Non-ASCII domain names are still problematic, to say nothing of non-ASCII email addresses. In other words, trying to speak UTF-8 to someone who only speaks ASCII is still as problematic as trying to speak IPv6 to someone who only speaks IPv4. We just don't notice it as much because we keep advising people to only speak ASCII in key places.
- zAy0LfpBZLC8mAC 9y ago
  > For email, this was true only about the mid-to-late 90s--surprisingly recent. Actually, email still is not nominally 8-bit transparent (ESMTP 8BITMIME is optional and not supported by all MTAs), but it doesn't need to be, that's what quoted-printable and base64 are for.
  - jcranmer 9y ago
    The timeframe I'm using is the timeframe where you stop seeing servers mangle 8-bit email. 8BITMIME technically requires converting 8-bit bodies to QP and base64, which is generally not necessary nowadays, and some would argue that software that chooses not to implement that shouldn't advertise 8BITMIME.
    - zAy0LfpBZLC8mAC 9y ago
      > and some would argue that software that chooses not to implement that shouldn't advertise 8BITMIME. Which is why I wrote that email still nominally isn't 8-bit clean :-) Yes, in practice, you won't find an MTA that doesn't leave your 8 bit data unharmed, but you do find MTAs that don't advertise 8BITMIME, and so nominally noone should send them 8 bit data ... except everyone does anyway, of course ...
zaphoyd 9y ago
Except UFT8 is not backwards compatible with ASCII! An application written to only understand ASCII will not print non-ASCII UTF-8 characters. That is what you are asking here. It can't be done with ASCII/UTF8. It can't be done with IPv4/IPv6.
- aexaey 9y ago
  UTF8 is backward compatible with ASCII just fine - latter is a strict subset of former. It doesn't get more backward-compatible than that! IPv6, on the other hand, is not at all backward compatible with IPv4 (was never a design goal - magic of OSI stack was supposed to do it's thing). One would argue that incompatibility is in large part responsible for the 6's slow start - even though afterthought bolt-ons eventually did see sunlight - ::ffff:x.x.x.x thing, cornucopia of tunnels and dual-stacks of various degree lite-ness, etc.
  - zAy0LfpBZLC8mAC 9y ago
    ... which means that if of two parties only one understand UTF-8, they have to speak ASCII. ASCII being a subset of UTF-8 does not provide and benefit in that regard, just as IPv4 addresses being a subset of IPv6 addresses wouldn't.
    - aexaey 9y ago
      Let me drill down it for you: Imagine two endpoints talking a backward compatible pair of standards: A only speaks ASCII, B only speaks UTF-8. Would you think they will be able to communicate at least something? Now imagine two endpoints talking a not backward compatible pair: A only speaks IPv4, and B only speaks IPv6. Will they be able to communicate, at least something? See the difference?
      - zAy0LfpBZLC8mAC 9y ago
        > Imagine two endpoints talking a backward compatible pair of standards: A only speaks ASCII, B only speaks UTF-8. Would you think they will be able to communicate at least something? As long as they only speak ASCII, yes. > Now imagine two endpoints talking a not backward compatible pair: A only speaks IPv4, and B only speaks IPv6. Will they be able to communicate, at least something? That's why you deploy IPv6 dual-stacked with IPv4. That way, if two parties only speak IPv4, it's completely backwards compatible. > See the difference? Sure do I see the difference. What I don't see is how to apply any of that to the v4 to v6 transition in a way that would have any advantage over how it is being done now.

The ASCII/UTF-8 backwards compatibility relies on (a) a large subset of data fitting within the constraints of ASCII and (b) most "upstack" applications being able to handle a few garbled/unrecognized characters. How does this map to routing packets on the internet, where the IP header contains time-sensitive metadata needed for delivery and the payload is largely agnostic of the differences?

zAy0LfpBZLC8mAC 9y ago

> Something more like UTF-8? Largely backwards compatible with old formats (ascii) while still being extensible. Which would work how exactly in the case of IP? So far sounds mostly like "make it backwards compatible by making it backwards compatible".

aexaey 9y ago
>> Largely backwards compatible > how exactly in the case of IP? For example, introduce two special IP options that would act as "page selector" for source and destination addresses respectively. i.e. SRC: 1.1.1.1, DST: 2.2.2.2, no options -> from 1.1.1.1 to 2.2.2.2 (backwards-compatible packet, classic IPv4) SRC: 1.1.1.1, DST: 2.2.2.2, opt.X: 1.1.1, opt.Y: 2.2.2 -> from 1.1.1.1.1.1.1 to 2.2.2.2.2.2.2 (our faux-IPv6) SRC: 1.1.1.1, DST: 2.2.2.2, opt.X: 0.0.0, opt.Y: 2.2.2 -> from 1.1.1.1 to 2.2.2.2.2.2.2 ("old" address communicating with "new" address) Last example of three is impossible with IPv4/6 dichotomy, and is most important for backward compatibility here - yes, "old" IP holder needs to upgrade their software too[1], but they don't need to get a new IP address, and as a result you don't end up with two isolated "Internets", a.k.a. dual-stack. Say, for ease of processing on router, require that X and Y would appear only together, in that order, preceding other options (which is a bit of an exception as far as IP options go, but again, a backward-compatible one). Now, I'm not proposing this seriously of course, but you asked for example - here you go, a plausible, backwards-compatible "IPv4.1", if you like. [1] All major desktop OS support IPv6 for last 10 years and major mobile OS for last 7. Let's face it - software upgrade turned out (surprisingly) not to be the biggest obstacle.
- teraflop 9y ago
  What advantage does that have over IPv6? From a backwards-compatibility perspective, it seems identical. In order for two hosts to communicate over IPv6, both ends need to have: software that supports IPv6, and the entire network path between them needs to be able to route IPv6 packets. Your proposal is functionally no different: you call the extended address field an "option", but in fact every host is required to understand it.
  - aexaey 9y ago
    I used term "options" here the way it was defined in RFC 791. [1] It's a standard way to extend IPv4 packet header. [1] https://tools.ietf.org/html/rfc791 https://tools.ietf.org/html/rfc791
- zAy0LfpBZLC8mAC 9y ago
  > Last example of three is impossible with IPv4/6 dichotomy, and is most important for backward compatibility here - yes, "old" IP holder needs to upgrade their software too[1], but they don't need to get a new IP address, and as a result you don't end up with two isolated "Internets", a.k.a. dual-stack. 1. What would be a scenario where hosts using this mechanism could communicate where neither IPv4 nor IPv6 would work? 2. How do new internet participants get addresses under your scheme, if it only expands the number of addresses in existing allocations?

jcranmer 9y ago

The ASCII->UTF-8 transition is arguably nearly as painful as IPv4->IPv6, and it's still nowhere near complete. Switching to UTF-8 requires two major steps. The first was making software and interchange systems preserve the 8th bit (it used to be commonly used as a parity bit). For email, this was true only about the mid-to-late 90s--surprisingly recent. The second step, which is still incomplete today, is letting control mechanisms that used to speak only ASCII understand UTF-8 (or something else non-ASCII) reliably. You could only put UTF-8 in C++ or C code as of C++11/C11, for example. Non-ASCII domain names are still problematic, to say nothing of non-ASCII email addresses. In other words, trying to speak UTF-8 to someone who only speaks ASCII is still as problematic as trying to speak IPv6 to someone who only speaks IPv4. We just don't notice it as much because we keep advising people to only speak ASCII in key places.

zAy0LfpBZLC8mAC 9y ago
> For email, this was true only about the mid-to-late 90s--surprisingly recent. Actually, email still is not nominally 8-bit transparent (ESMTP 8BITMIME is optional and not supported by all MTAs), but it doesn't need to be, that's what quoted-printable and base64 are for.
- jcranmer 9y ago
  The timeframe I'm using is the timeframe where you stop seeing servers mangle 8-bit email. 8BITMIME technically requires converting 8-bit bodies to QP and base64, which is generally not necessary nowadays, and some would argue that software that chooses not to implement that shouldn't advertise 8BITMIME.
  - zAy0LfpBZLC8mAC 9y ago
    > and some would argue that software that chooses not to implement that shouldn't advertise 8BITMIME. Which is why I wrote that email still nominally isn't 8-bit clean :-) Yes, in practice, you won't find an MTA that doesn't leave your 8 bit data unharmed, but you do find MTAs that don't advertise 8BITMIME, and so nominally noone should send them 8 bit data ... except everyone does anyway, of course ...

zaphoyd 9y ago

Except UFT8 is not backwards compatible with ASCII! An application written to only understand ASCII will not print non-ASCII UTF-8 characters. That is what you are asking here. It can't be done with ASCII/UTF8. It can't be done with IPv4/IPv6.

aexaey 9y ago
UTF8 is backward compatible with ASCII just fine - latter is a strict subset of former. It doesn't get more backward-compatible than that! IPv6, on the other hand, is not at all backward compatible with IPv4 (was never a design goal - magic of OSI stack was supposed to do it's thing). One would argue that incompatibility is in large part responsible for the 6's slow start - even though afterthought bolt-ons eventually did see sunlight - ::ffff:x.x.x.x thing, cornucopia of tunnels and dual-stacks of various degree lite-ness, etc.
- zAy0LfpBZLC8mAC 9y ago
  ... which means that if of two parties only one understand UTF-8, they have to speak ASCII. ASCII being a subset of UTF-8 does not provide and benefit in that regard, just as IPv4 addresses being a subset of IPv6 addresses wouldn't.
  - aexaey 9y ago
    Let me drill down it for you: Imagine two endpoints talking a backward compatible pair of standards: A only speaks ASCII, B only speaks UTF-8. Would you think they will be able to communicate at least something? Now imagine two endpoints talking a not backward compatible pair: A only speaks IPv4, and B only speaks IPv6. Will they be able to communicate, at least something? See the difference?
    - zAy0LfpBZLC8mAC 9y ago
      > Imagine two endpoints talking a backward compatible pair of standards: A only speaks ASCII, B only speaks UTF-8. Would you think they will be able to communicate at least something? As long as they only speak ASCII, yes. > Now imagine two endpoints talking a not backward compatible pair: A only speaks IPv4, and B only speaks IPv6. Will they be able to communicate, at least something? That's why you deploy IPv6 dual-stacked with IPv4. That way, if two parties only speak IPv4, it's completely backwards compatible. > See the difference? Sure do I see the difference. What I don't see is how to apply any of that to the v4 to v6 transition in a way that would have any advantage over how it is being done now.