Subject: [BEHAVE] I-D Action:draft-ietf-behave-address-format-02.txt

From: [email-masked]
Date: Sun, 13 Dec 2009 16:15:18 -0800 (PST)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF.

	Title           : IPv6 Addressing of IPv4/IPv6 Translators
	Author(s)       : C. Huitema, et al.
	Filename        : draft-ietf-behave-address-format-02.txt
	Pages           : 16
	Date            : 2009-12-13

This document discusses the algorithmic translated to a corresponding
IPv4 address, and vice versa, using only statically configured
information.  It defines a Well-Known Prefix for use in algorithmic
translations, while allowing organizations to also use Network
Specific Prefixes when appropriate.  Algorithmic translation is used
in IPv4/IPv6 translators, as well as other types of proxies and
gateways (e.g., for DNS) used in IPv4/IPv6 scenarios.

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups.  Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on June 17, 2010.Copyright Notice

Copyright (c) 2009 IETF Trust and the persons identified as the
document authors.  All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document.  Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.  Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-behave-address-format-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Dayong Guo <[email-masked]>
Date: Tue, 15 Dec 2009 11:49:13 +0800

Hi, all.
    draft-ietf-behave-address-format-02  recommends a zero suffix:   " In
the other cases, the remaining bits of the addressconstitute the suffix.
These bits are reserved for future extensions, and SHOULD be set to a zero.
"
    But RFC 4862 requires "DAD MUST be performed on all unicast addresses".
Because solicited-node multicast address is used in NS message of DAD,
hosts are seldom affected by DAD.
    So if there are many 0-suffix addresses in a subnet, solicited-node
multicast address will  be useless and too many DADs disturb hosts.
    
    Could DAD NOT be performed on the IPv4 Embedded IPv6 Address?  IPv4 can
play the same role of IPv6 DAD.

Guo Dayong

---

From: Christian Huitema <[email-masked]>
Date: Tue, 15 Dec 2009 04:15:37 +0000

> These bits are reserved for future extensions, and SHOULD be set to a zero.

The subnet prefix used on the link is supposedly the top level 64 bits of the IPv4 translatable IPv6 address. The host identifier is composed of bits 64-127. In most cases, the zero suffix does not translate in a zero identifier. This is only a problem if the NSP is /32, an option that we do not in fact recommend.

-- Christian Huitema

---

From: Dayong Guo <[email-masked]>
Date: Tue, 15 Dec 2009 15:29:11 +0800

see inline.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Christian Huitema
> Sent: Tuesday, December 15, 2009 12:16 PM
> To: Dayong Guo; [email-masked]
> Cc: [email-masked]
> Subject: Re: [BEHAVE] DAD and draft-ietf-behave-address-format-02
> 
> 
> The subnet prefix used on the link is supposedly the top 
> level 64 bits of the IPv4 translatable IPv6 address. The host 
> identifier is composed of bits 64-127. In most cases, the 
> zero suffix does not translate in a zero identifier. This is 
> only a problem if the NSP is /32, an option that we do not in 
> fact recommend.
> 
  RFC 4291 defines Solicited-Node Address:  FF02:0:0:0:0:1:FFXX:XXXX.
  The "XX:XXXX" is low-order 24 bits of an IPv6 address.

  For example, several IPv4 embedded IPv6 addresses with 0 suffix in a
share-link:
         2001:DB8:102:30D:1:4403::       [embed IPv4: 13.1.68.3, PL:
2001:DB8:102:300::/56]
         2001:DB8:102:30D:1:4404::       [embed IPv4: 13.1.68.4] 
         2001:DB8:102:30D:1:4405::       [embed IPv4: 13.1.68.5] 
         .......
  All of them derive the same Solicited-Node Address:FF02::1:FF00:0000. So
each DAD disturbs all hosts in a subnet.
I think that IPv4 Embedded IPv6 Addresses, except /96 prefix, have the same
problem. 

Dayong Guo