Subject: [BEHAVE] address-format: variable-length prefix, consensus check

From: Xing Li <[email-masked]>
Date: Sun, 06 Dec 2009 17:51:22 +0800

Hi, All,

In the draft-ietf-behave-address-format-01.txt, we defined variable
length approach of the address format. The reasons are:

(1) Different networks may have different length (/32, /48, /56, /64,
etc) of the network-specific prefix.
(2) The trade-offs for the routing efficiency, security and IPv6 address
consumption should be considered.
(3) The prefix lengths which across octet boundaries are not allowed.

The question asked to the audience in the behave meeting are: "Should we
recommend a default address format? Should it be let to the SPs to
decide? Do we allow other prefix lengths?"

There is no objections and questions, so we will keep the current
recommendations.

Choice of Prefix for Stateless Translation Deployments
o For scenario 1 (an IPv6 network to the IPv4 Internet) and scenario
2 (the IPv4 Internet to an IPv6 network), we recommend using a /40
prefix for an ISP holding a /32 allocation, and a /56 prefix for a
site holding a /48 allocation.
o For scenario 5 (an IPv6 network to an IPv4 network)
and scenario 6 (an IPv4 network to an IPv6 network),
we recommend using a /64 prefix.

Choice of Prefix for Stateful Translation Deployments
o For the WKP, the consensus is /96.

Please confirm.

Regards,

xing

---

From: Christian Huitema <[email-masked]>
Date: Sun, 6 Dec 2009 18:21:08 +0000

There is just one point that I wonder, the usefulness of the current /64 definition, compared to /96. Specifically, when mapping isolated networks, I may be tempted to recommend /96, or at least consider it. That would mean:

- for stateless deployments, adding a discussion item:

   We propose here a compromise, based on using no more than 1/256th of
   an organization's allocation of IPv6 addresses for the IPv4/IPv6
   translation service.  For example, if the organization is an ISP,
   with an allocated IPv6 prefix /32 or shorter, the ISP could dedicate
   a /40 prefix to the translation service.  An end site with a /48
   allocation could dedicate a /56 prefix to the translation service,
   or possibly a /96 prefix if all IPv4 Translatable IPv4 Addresses
   are located on the same link.

- for stateless deployment recommendations, adding an option:

   o  For scenario 5 (an IPv6 network to an IPv4 network) and scenario 6
      (an IPv4 network to an IPv6 network), we recommend using a /64 or /96
      prefix.

- for stateful deployments, adding an option:

   o  The Well-Known Prefix MUST NOT be used for scenario 3 (the IPv6
      Internet to an IPv4 network), as this would lead to using the
      Well-Known Prefix with non global IPv4 addresses.  That means a
      Network Specific Prefix MUST be used in that scenario,
	for example a /96 prefix compatible with the Well Known prefix 
      format.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Xing Li
Sent: Sunday, December 06, 2009 1:51 AM
To: 'Behave WG'; Behave Chairs
Subject: [BEHAVE] address-format: variable-length prefix, consensus check

Hi, All,

Please confirm.

Regards,

xing

_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 07 Dec 2009 09:54:52 +1300

> length approach of the address format. The reasons are:

...
> o For the WKP, the consensus is /96.

No problem with this, but should it be stated somewhere that
the u/g bit retains its significance in this case? This isn't
100% clear from the text in section 2.

   Brian

---

From: Christian Huitema <[email-masked]>
Date: Sun, 6 Dec 2009 21:45:17 +0000

> 100% clear from the text in section 2.

It is actually stated in the draft, section 2:

			... When using a 96 prefix, the administrators
   MUST ensure that the bits 64 to 71 are compatible with the IPv6
   addressing architecture.

We could add text, e.g. "A simple way to achieve that is to construct the /96 prefix by picking a /64 prefix, and then add four octets set to zero."

The u/g bits are not technically required if the WKP is picked in the 0::/8 range, since the requirement is only stated for the 2000::/3 range. But leaving the bits null in the WKP does not hurt.

-- Christian Huitema

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 07 Dec 2009 11:37:38 +1300

>    MUST ensure that the bits 64 to 71 are compatible with the IPv6

Ah, OK, thanks.

> We could add text, e.g. "A simple way to achieve that is to construct the /96 prefix by picking a /64 prefix, and then add four octets set to zero."

Sure.

> The u/g bits are not technically required if the WKP is picked in the 0::/8 range, since the requirement is only stated for the 2000::/3 range. But leaving the bits null in the WKP does not hurt.

Correct, that is still a little vague in the IANA Considerations of version 01.
Maybe it is time to tighten up the language there?

    Brian