Subject: re: [BEHAVE] address-format: bits 64 to 71

From: Xu Xiaohu <[email-masked]>
Date: Wed, 09 Dec 2009 17:58:48 +0800

Since the following email is not successfully received by some subscribers,
so I resend it.

Xiaohu

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表
Brian 
> E Carpenter
> 发送时间: 2009年12月9日 5:40
> 收件人: Xu Xiaohu
> 抄送: [email-masked]; [email-masked]; 
> [email-masked]
> 主题: [BEHAVE] address-format: bits 64 to 71
> 
> On 2009-12-08 21:54, Xu Xiaohu wrote:
> >
> >> -----邮件原件-----
> >> 发件人: [email-masked] [mailto:[email-masked]] 代表
> >> Christian Huitema
> >> 发送时间: 2009年12月8日 2:52
> >> 收件人: [email-masked]; [email-masked];
> [email-masked];
> >> [email-masked]
> >> 主题: Re: [BEHAVE] address-format: null suffix, consensus check
> 
> ...
> > Hi Christian,
> >
> > I noticed the following statement in your draft "...Bits 64 to 71 of 
> > the
> address are reserved for compatibility with the host identifier format 
> defined in the IPv6 addressing architecture. These bits MUST be set to 
> zero.  The corresponding octet is noted "u" in the above diagram.  
> When using a 96 prefix, the administrators MUST ensure that the bits 64 to
71 are compatible with the
> IPv6   addressing architecture..."
> >
> > My question is: Should the IPv4-embeded IPv6 address still be in 
> > accordance
> with the specification defined in RFC4291 as "...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..."?  If the answer is yes, why? (In other 
> words, is there any practical meaning/usage for that constraint in the 
> IPv4/IPv6 translation process?)
> 
> I thought we'd discussed that a lot. Maybe it was not on the BEHAVE list.

Yes, we had discussed that in both SOFTWIRE and BEHAVE WG mailing-lists (see
the previous discussion thread:
http://www.ietf.org/mail-archive/web/softwires/current/msg00850.html.).
However, we have not got any reasonable enough answer.

> The idea of protecting the semantics of the u/g bit (which is most 
> cleanly done by skipping the whole byte) is that it is a very 
> fundamental part of the IPv6 design and we simply do not know when or 
> how it might be relied on. It may have no value in currently 
> understood cases of 1:1 communication via a NAT64, but we don't know 
> where it might be important in p2p communications, referrals, etc.

The following statement is quoted from RFC 4291:
   "IPv6 nodes are not required to validate that interface identifiers
   created with modified EUI-64 tokens with the "u" bit set to universal
   are unique.

   The use of the universal/local bit in the Modified EUI-64 format
   identifier is to allow development of future technology that can take
   advantage of interface identifiers with universal scope."

Till now, we haven't known the real usage of this constraint yet. So we
should reverently obey such a constraint whose future usage is still
uncertain. 

Maybe a compromised way is to release this constraint on the IPv4-embeded
IPv6 addresses which can be used for stateless IPv4/IPv6 translation and
6over4 automatic tunneling while remaining it for native IPv6 address
auto-configuration in case using a /64 prefix.

> Also, this WG doesn't own the address format. Changing this would need 
> the consensus of 6man.

OK, I have added the 6man in the cc. Look forward to a clear conclusion
after discussing it in the 6man mailing-list.

Xiaohu

---

From: Jeroen Massar <[email-masked]>
Date: Wed, 09 Dec 2009 11:24:24 +0100

> Since the following email is not successfully received by some subscribers,

You might want to try and subscribe to [email-masked] to resolve part of
that issue, otherwise everytime you sent something it ends up in the
moderation queue....

Greets,
 Jeroen