Hi Fred,
Let me address this.
A few French people gathered around me over the last two years as
they wanted to see how we could technically protect the Project.FRA
of a francophone TLD, and other linguistic and culturally related
TLDs; and thereby to find a way to technically obtain an Internet
that would be "people oriented, caractère humain, centrada en la
persona", which is exactly what the WSIS unanimously declared that
the information society had to be. This meant a clear border in the
same technology (RFC 1958) between what was simplified (RFC 3439) by
the engineers, and what was individually decided by the people's diversity.
This has led to the IDNA2008 consensus and RFC set. The solution was
qualified as "unusual" in RFC 5895. This is because we identified
(and this is why I could join the consensus) and illustrated that a
part of the people's peer to peer relation had to be intelligently
supported at the fringes, i.e. outside the end to end connection: off
the wire/rope. In the IDNA2008 case, it is the UTF-8 entry that is to
be translated into ASCII and we identified that there could be an
unlimited number of ways of doing it, depending on the language,
script, and context. In other areas this can be the addresses, the
referentials, the meanings, the economic nature of the relation, the
network time, the content, etc.
"unusual" meant that things are to be coordinated after the socket,
outside of the Internet, at the users' machines. This meant there is
a network side and a network use side. In the case of IDNA, we also
identified that the network use side is not the user's side. Hence,
the need/existence of an Internet Use Interface (IUI) middle-capacity
to be explored, documented, and experimented.
1. The first question was, therefore, where was it best to document
such an IUI?
2. The second question was that the division between the internal,
peripheral, and external internets permitting a multiplication of
additions/changes/extensions to the way we currently use the Internet
without changing a single bit to the internal internet, how to best
manage the transition towards what was, therefore, only a different
reading context of the same RFCs?
3. The third issue was that the decoupling of the external user's
from the network technology by a smart IUI permitting the
consideration of a user centric capability to simultaneously use any
alternative technology, internet evolution, new generation
architecture, new addressing plan, new name spaces, etc.
Point (1) was addressed by my appeal to the IESG and IAB for not
warning the community about the fundamental change in the reading of
the Internet architecture IDNA2008 introduced and illustrated. The
target was to quickly make sure that the IETF was or was not the
proper place to document the IUI. The responses showed that the IETF
felt concerned by the implication but did not want to be the
designated IUI place.
Point (2)'s main immediate extension is the ML-DNS (i.e. a multilayer
DNS, through an intelligent front-end for a strictly respected DNS).
I announced it three years ago as a future continuation of IDNA2008
once it would be settled. I am a few months late, but its principle
has been experimented for a long time and I should be able to release
an experimental prototype soon. This will be an "interbox" user
(Linux/Windows) software including its own DNS server and a
functional CLASSES/actions dispatcher. This opens up a very large
number of possibilities including an unlimited virtual root, classes,
and presentations, the full use of naming (identification,
declaration, denomination), support of an interapplication system,
etc. and the IDv6 support (see below). Unfortunately ICANN chose to ignore it.
Point (3) actually identifies the emergence of a new community, the
Intelligent Users community, we abbreviate this as IUsers (also good
for what I and others are: lead users) or the "IUse" community. It
corresponds to the first layers that we added to OSI
(interapplications, pseudo-network applications, and in the Internet
case, presentation), towards the Intersem architecture (i.e. the
Internet of thoughts) that needs them. The Intersem must be
considered as an intricate network of person's systems, we call them
cybships, in technical symbiosis but culturally empowered if we do
not want everyone think "google".
In terms of internal addressing, the needs and possibilities that we
have are large because we want to be able to support a large number
of "plug-and-play" applications and a broad number of different
classifications. This means that IPv6 IIDs are the best
practical/available choice. Since we can use them anywhere to connect
anything, we use the word IDv6 to designate them even outside of the
IPv6 environment. We use "GRIDv6" (Global Region IDv6) for
specialized addressing plans that people can use, for example for
linguistic address translation functions (giving each concept/notion
an address that we might use for semantic addressing), etc.
We consider domain name labels as alphadigital (0-Z) numbers with the
"-" as a sub-label separator. This means that we can easily
conceptually handle IDv6 as 1 to 13 alphadigital long domain name
labels (one or several labels separated by a dot [two more than a DOS
file names, e.g.: an.ipv6.address.jefsey.com]).
This is why your NPTv6 seems to be a good solution for us. With a
long IETF background. It could also be quickly implemented in the
Interbox testing project. I discussed something similar with Houlin
Zao in 2005 for an ITU/3 block, differentiating the routing part from
the local addressing part. Moreover, we could then use LISP like
sub-sub-addresses for deeper local (host) addressing.
At 23:52 08/12/2010, Fred Baker wrote:
Let me know, unicast, if I can help. You will find a need to track
the draft as it progresses, as it is not in final form until it's an RFC.
I think the acronyms you're looking for are all specified in the
draft. For example, the GSE draft, as noted in the spec, is a
reference to a particular draft, and a ULA is specified in RFC 4193.
Are there any in particular that I have not given the reference for?
No, thank you it is OK. Marie-France's remark was a good one. She
would like me to present them NPTv6 as a compact IUser oriented with
all the relevant issues introduced in the same document. The IUCG is
meant to interface the IETF and Lead Users (people who are ready to
modify their internet for it to suit their needs and who are not used
to standardization, nor have time for participating). If I can
transform your RFC in an IUse Best Practice equivalent, it means both
sides of the IUI are in tune.
The ULA concept seems acceptable, but there is a risk of conflict and
complexity? At our level we thought of a default local prefix, since
GRIDv6 would already be used.
Is there a specification, in English, of what you want in your IDv6
or "iUsers kind of way"? Given questions, the IETF is here to
provide answers... I have poked around on the IUCG wiki, but to be
honest I don't see much there to respond to.
No. All of this is emerging right now, after the response of the IAB
and IESG, and the IAB road map, we want to carefully consider it all.
This is really a bootstrap period. We started preparing with some
IUCG pages on the Inteplus, but since this is to be multitechnology,
a public domain stream looks more appropriate.
Actually my plan, now that we have clearly identified the principle
and the first priorities, is to explore in testing and to discover
what is possible with a few real life projects such as "Projet.FRA"
(a francophone open ontology TLD using its namespace as a taxonomy),
and "Multilinc" (multiple linguistic TLDs, to explore
multilingualization, i.e. languages working together at the common
tools level) and may be "PERFIDA" (a private use RFID oriented space).
The adjustment:
We are keeping the TCP and UDP checksums intact between the inside
and the outside networks; these include a "pseudoheader" which is a
subset of the IP header, so a change to those parts of the IP header
has to change the checksum. To do so, we either have to update them
in the TCP or UDP headers, which means that we can't encrypt data
(IPsec) or that the router has to parse through all of the IPv6
sub-headers to find the transport header. We update the checksum
calculation in the IP address in order to avoid those issues.
Yes. This is a smart idea! (But we have not the expertise of Rémi
Desprès to analyse it and question some details).
Too bad it makes us lose two bytes in the address (unless IPSec is
carried in the IUI - after the NPTv6 process?). We would need to
indicate somewhere that we could use an extended IPv6 header. We have
needs for that, but it is too early to discuss this. Our priorities
are to test the InterPlus concept (Plugged Layers on the User Side)
with the ML-DNS and internal IDv6 ported by 3rd or 4th level domain names.
GSE
I understand that an edge network may have several upstreams that it
can use to send (and rotate upstreams) but also that on each of these
upstreams it has a different address.
jfc
_______________________________________________
nat66 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nat66
