I have another comment/question (bit late, but I thought I could better mention it before people reissue the draft):
Section 2.5.5 says: "A second type of IPv6 address which holds an embedded global IPv4 address is also defined. This address type is used to represent the addresses of IPv4 nodes as IPv6 addresses. This type of address is termed an "IPv4-mapped IPv6 address" and ... Why is the definition of ipv4-mapped restricted to global ipv4 addresses? I can imagine applications in which one wants to embed a local ipv4 address in an ipv6 format. Or should one use a variant of ipv4-mapped with a site-local prefix for this case? Maybe this requires another way of defining ipv4-mapped: | 80 bits | 16 | 32 bits | +--------------------------------------+--------------------------+ |prefix|0000.......................0000|FFFF| IPv4 address | +--------------------------------------+----+---------------------+ Prefix could possible also be the multicast prefix in case one wants to map an ipv4 multicast address in an ipv6 format. dirk Bob Hinden wrote: > > The IPng working group last call for Draft Standard for: > > 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 > > was completed on August 31, 2001. A summary of the comments received on > the mailing list and their disposition is attached. Note: Editorial > comments are not included in this summary. > > Once a new version of the draft is issued, the document can be forwarded to > the IESG for Draft Standard. > > Bob Hinden & Steve Deering > > ------------------------------------------------------------------------ > > COMMENT 1: Suggestion that it isn't good practice to talk about assigning > multicast address to an interface because it may confuse people and they > might be assigned directly to interfaces (e.g., via ifconfig command). > > Text will be changed to clarify this issue. > > COMMENT 2: Questioned whether the IPv6 addresses with embedded IPv4 address > should be included in the document. > > This was discussed at the interim meeting in Seattle and there was a > consensus to keep the mapped and compatible address in this > document. Other types of transition addresses can be defined in other > documents. > > COMMENT 3: Suggestion that the anycast usage scenarios in the document are > very router centric and restrictions for router only usage be eased. > > The current text will be revised to clarify that other anycast usage is > possible, but that new uses need to be specified. > > COMMENT 4: Suggestion that there be more clarification on the differences > between interface, link, and node in section 2.7 on multicast addresses. > > Will add a summary description of the multicast scope values to the document. > > COMMENT 5: Questioned the removal of the format prefix (FP) and detailed FP > table, and instead only listing the exceptions to global unicast. > > This issue was discussed on the mailing list and there was a consensus that > the current text is appropriate. The resulting behavior of treating the > address space as global unicast, except for the listed exceptions, is correct. > > COMMENT 6: Suggestion to reserve some part of the IPv6 and have it's usage > be unspecified. > > The discussion on the mailing concluded was this was not a good idea. Past > experience with IPv4 indicated that it becomes very hard to utilize > "unspecified" address space in the future. > > COMMENT 7: Suggestion to move IANA considerations to a numbered section > instead of an appendix to make clearer it is normative. > > Document will be updated to make the IANA consideration a numbered section. > > -------------------------------------------------------------------------- > > -------------------------------------------------------------------- > 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] > -------------------------------------------------------------------- -- Dirk Ooms mailto:[EMAIL PROTECTED] tel:+32 3 2404732 Network Strategy Group (NSG) http://aww.alcatel.com/nsg Alcatel http://www.alcatel.com -------------------------------------------------------------------- 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] --------------------------------------------------------------------
