comments on draft-ietf-ipv6-addr-arch-v4-00.txt

[itojun@iijlab.net]

	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
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------