as an IAB i was asked to comment on draft-ietf-ipv6-addr-arch-v4-00.txt,
so here it is. happy holidays.
itojun
MAJOR
=====
"scope"
the use of word/concept "scope" needs more care. moreover the
terminology is not consistent (such as "link-scope" and "local scope").
(maybe this is because there is a separate draft for scoped address
architecture, but anyways, first-time readers will get confused).
multicast scope is well documented in 2.7. the problem is in the way
unicast scope is documented.
here are use of unicast "scope" in the document (maybe i missed some of
those):
2.1: link-scope
2.4: of any scope
2.5.1: over a broader scope
local scope interface identifier
universal scope interface identifier
universal scope (multiple occurrences)
local scope (multiple occurrences)
2.5.3: link-local scope
solution: there has to be a section describing what the unicast "scope"
is, in very early part of the document. it can be very simple as there
are only two scopes - link-local and global.
use terminology such as "link-local scope" or "global scope"
consistently.
another solution: refer to scoped address architecture document.
however, it will create dependency to scoped address architecture
document which is not very desirable.
it seems that the document tries to use "universal scope" to refer
the scope of global unicast address, however, it is a bit confusing.
maybe it is better to use "global scope" - in fact, ff0e::/16 is
called "global scope", not "universal scope".
textual representation
2.2 (1) has to state how many digits are permitted as "x"
(one component between colon). my personal preference is that
"x" has to be 1 to 4 digits (5 digits or more is invalid).
remove "::13.1.68.3" from example for (3), as we no longer have
IPv4 compatible address (not to confuse readers).
IPv4 mapped address
if I remember correctly draft-itojun-v6ops-v4mapped-harmful-02.txt
(IPv4 mapped address on-wire is harmful) got enough consensus. please
document that IPv4 mapped address is not permitted on wire, in 2.5.5.
i know this is not a document to discuss on-wire stuff, however,
there's no better place to document it.
IPv4 compatible address
2.5.5 states that "The IPv6 transition mechanisms [TRAN] include..."
for IPv4 compatible address. however, [TRAN] (RFC2893) no longer
includes automatic tunnel.
solution: mark IPv4 compatible as historic, just like site-local.
EUI64
the last paragraph in 2.5.1 is incorrect: it states that "Interface IDs
are required to be 64 bits long and to be constructed in Modified
EUI-64 format". however, after "and" (EUI64 portion) is not true.
(it is not required to construct interface ID based on EUI64 format,
moreover, EUI64 method is applicable only to interfaces of certain
media types)
MINOR
=====
NSAP address
2.5 and 2.5.4 talks about "encoded NSAP address" which is not of
interest for many of the readers. i'd suggest removing it.
there could be other places where encoded NSAP address is mentioned.
(is it used in practice? it'll be interesting to see the
implementation report when the document advances to DS)
security consideration
it may be worthwhile to state that noone should use addresses as
authenticator - AH (or ESP) has to be used instead.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
