Subject: unicast address with non 64 bit prefix

From: Washam Fan <[email-masked]>
Date: Fri, 15 Jul 2011 15:03:47 +0800

Hi,

I quoted this paragraph from RFC4291:

   For all unicast addresses, except those that start with the binary
   value 000, Interface IDs are required to be 64 bits long and to be
   constructed in Modified EUI-64 format.

But I am not sure how to interpret the text in  a correct way.

If I assign an ordinary unicast address (except reserved anycast
addresses mentioned in RFC5453) to an interface and the address
doesn't start with 000, MUST the prefix be 64 bits? MUST the IID be
constructed in Modified EUI-64 format?

We are providing WebUI for our customer to manually assign IPv6
addresses, we want to do hygiene check before the actual move.

Thanks in advance
washam

---

From: Kerry Lynn <[email-masked]>
Date: Fri, 15 Jul 2011 07:26:59 -0400

See also section 2.5.4 of RFC 4291:
"All Global Unicast addresses other than those that start with binary
 000 have a 64-bit interface ID field (i.e., n + m = 64), formatted as
 described in Section 2.5.1."

So I'd say the answer is the IID MUST be 64 bits long, and MUST
satisfy the properties of uniqueness discussed in 2.5.1 (and set the
"u" bit accordingly).  An IID in modified EUI-64 format satisfies these
requirements, but in general IIDs are formed according to rules specified
by the particular "IP over ..." RFC, e.g. RFC 4944.  For example, an
actual EUI-64 may be preferred for interfaces that have them.
Finally, those with privacy concerns may elect methods for creating
IIDs that mask the underlying hardware identifier; see RFC 3041.

HTH, -K-

On Fri, Jul 15, 2011 at 3:03 AM, Washam Fan <[email-masked]> wrote:

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 16 Jul 2011 10:25:11 +1200

The authors of RFC 4291 chose not to use the upper case normative
keyword convention defined in RFC 2119. Therefore, 'required' means
what in means in plain English (i.e. REQUIRED in RFC2119ish).

   Brian

---

From: Kerry Lynn <[email-masked]>
Date: Fri, 15 Jul 2011 20:57:54 -0400

Brian, you're quite right.  I had in mind only one particular class of IID.

Washam, see Appendix A of RFC 4291 regarding modified EUI-64 IIDs
with "u"=0.  Also, RFC 3041 has been obsoleted; see RFC 4941 and
its errata if privacy issues apply in your situation.

-K-

---

From: Washam Fan <[email-masked]>
Date: Sun, 17 Jul 2011 00:02:55 +0800

THanks Kerry and Brian,

Now we provide 3 parameters to our customers to configure a IPv6
address manually: 128bit address, subnet prefix and default gateway
(optional, if it is provided, it should be within the same subnet with
the 128bit address). Should we set subnet prefix to a fixed value 64
if the 128bit address starts with 001-111?
(ipv6 is a new feature in our appliance, we don't have much
experiences about it)
Thanks,
washam
PS: should we allow our customer configure 128bit address starting
with 000 in the first place?

2011/7/16 Kerry Lynn <[email-masked]>:
> On Fri, Jul 15, 2011 at 6:25 PM, Brian E Carpenter
> <[email-masked]> wrote:
>>

---

From: Washam Fan <[email-masked]>
Date: Sun, 17 Jul 2011 10:45:39 +0800

Hi Kerry,

Yes, they can be derived from PIO. But is there any possibility
customers manually set subnet prefix?

Now, we disable SLAAC on the appliance (due to it provides important
services like web proxy/cache, web filtering, traffic monitoring) and
use the 3 parameters to configure IPv6 addresses.
#ip -6 addr add <host-addr>/<prefix-len> dev eth0
#ip -6 route add default via <gw-addr>

in our current design, the customer is allowed to set prefix-len to
non-64 value like 65. But according to discussions in this thread, it
seems to me we SHOULD NOT allow our customers to set prefix-len to
non-64 value unless they assign an address starting with 000.(Ask
again, should we allow our customers to assign an address starting
with 000 in first place?)

Are you saying we should only allow customers to set IID. let
prefix-len and gw-addr derived from ND interactions?

As I stated before, we are adding ipv6 feature to our product, we
don't expect ipv6 will be used by majority of our customers ( IPv6 is
disable by default on our products). But we want to do the right thing
at the begining.

THanks,
washam
2011/7/17 Kerry Lynn <[email-masked]>:
> The subnet prefix generally comes from the router on the link
> via Router Advertisements (e.g., Google radvd).  It's not
> something the customer needs to set.
> -K-
>
> On Sat, Jul 16, 2011 at 12:02 PM, Washam Fan <[email-masked]> wrote:
>>
>> THanks Kerry and Brian,
>>

---

From: Karl Auer <[email-masked]>
Date: Sun, 17 Jul 2011 13:35:31 +1000

> with 000 in first place?)

I suggest either a warning/confirm if they use a non-64-bit IID ("You
have just configured a non-standard interface ID! Proceed?") or
alternatively have a checkbox somewhere "allow non-64-bit (non-standard)
interface IDs".

Regards, K.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer ([email-masked])                   +61-2-64957160 (h)
http://www.biplane.com.au/kauer/                   +61-428-957160 (mob)

GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687
Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156