Bob,
Apologies for a late set of comments.
I. Esthetics: (this was true in earlier incarnations of the document)
There are 3 numbered sections in the document, which is a very
conservative use of
section numbering.
Practically there is only one section, section 2, that has more than a
couple of paragraphs of content.
Each of the next level subsections of section 2, could be independent
sections by themselves. The text representation could be grouped in one
section, plus two subsections.
Etc...
For instance:
(current)
2. IPv6 Addressing
2.1 Addressing Model
2.2 Text Representation of Addresses
2.3....
(suggested)
2. Addressing Model
3. Text Representation
3.1 Representation of Addresses
3.2 Representation of Prefixes
4. Address Type Representation
5. Type of Addresses
5.1 Unicast Addresses
5.2 Anycast....
etc....
II. Address space fully allocated.
It seems that the new document specifies an address space which is fully
allocated for IPv6.
There is no space set aside at this time for experiments, or future use,
while the future carving of the space is left to future specifications.
The model in which space was set aside ahead of time worked well in
IPv4, while the experience of carving out space from space already
allocated for one purpose never worked well before, or it does not
currently.
Therefore I am a strong supporter of having some space set aside now -
two chunks: experimental, and reserved.
III Multicast address local scopes.
The document defines now:
interface-local
subnet-local
admin-local
site-local
organizational-local
Some of the names used are self-explanatory, but others are not, and no
explanations are
given, or references to other documents, which I do not think it is
good.
For instance, I am not sure what what "interface local" means.
"interface-local" means forwarding within the interface? Does not make
too much sense to me.
"node local" was dropped, although through its name it made sense as
scope for multicast packets forwarded internally, within a node, but
which never left the node.
Regards,
Alex
, or
Bob Hinden wrote:
>
> This is a short IPng working group last call for comments on advancing the
> following document as an Draft Standard:
>
> Title : IP Version 6 Addressing Architecture
> Author(s) : B. Hinden, S. Deering
> Filename : draft-ietf-ipngwg-addr-arch-v3-06.txt
> Pages : 27
> Date : 19-Jul-01
>
> A complete list of changes from RFC-2373 is in Appendix B of the draft and
> is reproduced below.
>
> Please send substantive comments to the ipng mailing list, and minor
> editorial comments to the authors. This last call period will end one
> week from today on August 31, 2001.
>
> We are doing a short w.g. last call because there have been earlier w.g.
> and IETF last calls on this document and wanted to insure that the changes
> in the current draft has been reviewed by the w.g.
>
> Bob Hinden / Steve Deering
>
> --------------------------------------------------------------------------
>
> APPENDIX B: Changes from RFC-2373
> ---------------------------------
>
> The following changes were made from RFC-2373 "IP Version 6
> Addressing Architecture":
>
> - Many small changes to clarify and make the text more consistent.
> - Revised sections 2.4 and 2.5.6 to simplify and clarify how
> different address types are identified. This was done to insure
> that implementations do not build in any knowledge about global
> unicast format prefixes. Changes include:
> o Removed Format Prefix (FP) terminology
> o Revised list of address types only includes exceptions to
> global unicast and a singe entry that identifies everything
> else as Global Unicast.
> o Removed list of defined prefix exceptions from section 2.5.6
> as it is now the main part of section 2.4.
> - Clarified text relating to EUI-64 identifiers to distinguish
> between IPv6's "Modified EUI-64 format" identifiers and IEEE
> EUI-64 identifiers.
> - Combined the sections on the Global Unicast Addresses and NSAP
> Addresses into a single section on Global Unicast Addresses,
> generalized the Global Unicast format, and cited [AGGR] and [NSAP]
> as examples.
> - Reordered sections 2.5.4 and 2.5.5.
> - Removed section 2.7.2 Assignment of New IPv6 Multicast Addresses
> because this is being redefined elsewhere.
> - Added an IANA considerations section that updates the IANA IPv6
> address allocations and documents the NSAP and AGGR allocations.
> - Added clarification that the "IPv4-compatible IPv6 address" must
> use global IPv4 unicast addresses.
> - Divided references in to normative and non-normative sections.
> - Added reference to [PRIV] in section 2.5.1
> - Revised section 2.4 Address Type Representation to
> - Added clarification that routers must not forward multicast
> packets outside of the scope indicated in the multicast address.
> - Added clarification that routers must not forward packets with
> source address of the unspecified address.
> - Added clarification that routers must drop packets received on an
> interface with destination address of loopback.
> - Clarified the definition of IPv4-mapped addresses.
> - Removed the ABNF Description of Text Representations Appendix.
> - Removed the address block reserved for IPX addresses.
> - Multicast scope changes:
> o Changed name of scope value 1 from "node-local" to "interface-
> local"
> o Defined scope value 3 for "subnet-local" for multi-link
> subnets
> o Defined scope value 4 as "admin-local"
> - Corrected reference to RFC1933 and updated references.
>
> ------------------------------------------------------------------------
>
> --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home Page: http://playground.sun.com/ipng
> FTP archive: ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to [EMAIL PROTECTED]
> --------------------------------------------------------------------
S/MIME Cryptographic Signature
