At 23:51 15/03/2011, Fred Baker wrote:
Rather than quote RFC 3439 on the topic, I'll simply encourage
people to read its comments on complexity, amplification, and
especially coupling, which may be found at
http://tools.ietf.org/html/rfc3439#section-2. When you couple
layers together, things go belly up. Instead of complaining about
the fact, which the IETF makes a grand past-time of and this thread
is a case in point, start thinking about how to not couple them.
Amen.
This is, however, IPv6 built-in. From designers' point of view there
is an IPv6 address.
From a user point of view, there are three address layers supported
by three address segments in an "IPv6 address", that are rather
similar to domain name levels (and that can be supported by domain
name levels):
- the IDv6 user defined regional addressing plan (64 bits)
- the GRIDv6 user announced regional ID (the extension to 64 bits of
the network address below or the leading bits of the IDv6 segment
if the network address is 64 bits)
- the IPv6 network address, i.e. the leading block provided by the
ISP - the part you want to change.
The most difficult part for us is obviously the fuzzy GRIDv6
identification. There could be a negotiation or the use of bit 65, to
be set to 0 or 1 in order to indicate where the GRIDv6 info is located.
To better accept this, please remember that the IDNA2008 resolution
has introduced subsidiarity as the way to address diversity. The
English language actually lacks two words to fully describe
subsidiarity in this case:
- what could be translated as "active subsidiarity" from French
"subsidiarité active", which is a poor word for the concept of
"matching unity and diversity", I would prefer to translate as
"progressive or layered subsidiarity". This is what happens in the
Internet. Introducing subsidiarity in higher (new) fringe to fringe
layers is the way to protect unity in the lower (most, if not all)
end to end layers.
- what I do not know how to translate in English is the "principe de
suppléance", which means that when subsidiarity fails, the upper
level or collaterals or even the lower level are to provide help
while respecting the subsidiarity principle. This is the way
subsidiarity scales. Beware: this is not by solidarity, as it is
sometimes translated. Solidarity is centered on each subsidiary level
that needs cooperation because something failed and it requires a
patched solution, which is to be carried out together on the
occasion. Suppléance is a built-in governance mechanism that
everyone can rely upon as acting as necessary, but not more than
necessary, when and only when needed. Solidarity is occasional, and
suppleance capacity is permanent. Suppleance is a governance
principle, while solidarity is a survival solution.
For example, this should be the role of ICANN in naming and
addressing. Hierarchy is based on ruling, and subsidiarity is based
on serving. Suppleance is the way that this serving scales. When I
say that IDv6 can be supported by domain names translated into IIDs,
this is by the suppleance of the inability of IPv4 to support local
IIDs. When Fred proposes NPTv6, this is the simplest (RFC 3439) way
to apply the suppleance principle among collaterals.
jfc
_______________________________________________
nat66 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nat66
