Subject: Reason(s) for Modified EUI-64 format to apply to ALL non-0::/3 IPv6 addresses ?

From: Rémi Després <[email-masked]>
Date: Tue, 08 Dec 2009 12:26:24 +0100

Hi all,

Xu Xiaohu wrote (in the Behave discussion thread) :

> 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?

+1 in favor of this question being answered by those who know the history.
(This question is a recurring one, AFAIK not answered so far.)

> (In other words, is there any practical meaning/usage for that 
> constraint in the IPv4/IPv6 translation process?)

If no reason for the current constraint is reported, the real constraint 
could be weaker, becoming for example:

"...For all unicast addresses other than those that start with the
binary value 000, and that are used as destinations on IPv6 links having
/64 subnet prefixes, Interface IDs are required to be constructed in
Modified EUI-64 format."

To be complete, it could be added that:

"If new formats are defined in the future for such Interface IDs, they
should be distinguishable from the Modified EUI-64 format, i.e. should
have their two lower bits of the first octet both set to 1"

NOTE: IPv4-translatable and IPv4-converted IPv6 address formats are 
being defined in conformance with the Modified EUI-64 format constraint. 
*This doesn't need to change.*
(Even if not technically necessary, this conformance permits to freeze
the specification, which is urgent, without waiting for the above
question to be resolved.)

Regards,

RD

---

From: Xu Xiaohu <[email-masked]>
Date: Wed, 09 Dec 2009 09:52:14 +0800

> -----邮件原件-----
> 发件人: [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..."
> >
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

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

---

From: Christian Huitema <[email-masked]>
Date: Wed, 9 Dec 2009 02:26:22 +0000

> It seems ok to redefine the specification once the constraint on
> IPv4-embeded IPv6 addresses has been removed, just as what we are now doing
> on SIIT. (E.g., replacing the IPv4-Compatible IPv6 Address and IPv4-Mapped
> IPv6 Address with IPv4-translatable IPv6 address and IPv4-converted IPv6
> address respectively).

Any revision of the IPv6 addressing rules in 6MAN is going to take a long time. Maybe several years. I would rather not wait that long before we publish the addressing format document. Beside, complying with the rule is not that hard. So why bother?

-- Christian Huitema

---

From: Christian Huitema <[email-masked]>
Date: Wed, 9 Dec 2009 05:20:27 +0000

> At least the former usage has some certain applications. For example, in
> case of NAT64, if a dual-stack host could distinguish synthesized IPv6
> addresses from native IPv6 addresses, it will not prefer a synthesized IPv6
> address to an IPv4 address for initiating a communication with an IPv4 host.

The well known prefix is easy to recognize, so there is no problem there. For stateless, the design makes sure that the IPv4 translatable addresses can be routed natively, which means there is no reason to not prefer them. That leaves a pretty small domain of applicability for any scheme that would reserve identifier patterns...

-- Christian Huitema

---

From: Xu Xiaohu <[email-masked]>
Date: Wed, 09 Dec 2009 10:18:10 +0800

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表 Ré
mi
> Després
> 发送时间: 2009年12月8日 19:26
> 收件人: [email-masked]; [email-masked]
> 抄送: Xu Xiaohu
> 主题: [BEHAVE] Reason(s) for Modified EUI-64 format to apply to ALL
non-0::/3
> IPv6 addresses ?

> could be weaker, becoming for example:

Agree.

> /64 subnet prefixes, Interface IDs are required to be constructed in

How about the IPv4 translatable addresses for IPv6 hosts in the stateless
translation case? Obey the constraint or not?

Xiaohu

---

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

> -----邮件原件-----
> 发件人: Christian Huitema [mailto:[email-masked]]
> 发送时间: 2009年12月9日 10:26
> 收件人: Xu Xiaohu; 'Rémi Després'; [email-masked]; [email-masked]
> 主题: RE: [BEHAVE] Reason(s) for Modified EUI-64 format to apply to ALL
> non-0::/3 IPv6 addresses ?
> 
> Any revision of the IPv6 addressing rules in 6MAN is going to take a long
time.
> Maybe several years. I would rather not wait that long before we publish
the
> addressing format document. Beside, complying with the rule is not that
hard.
> So why bother?

I wonder whether one could use that octet (bit 64 to 71) of IPv4-embeded
IPv6 address for identifying different types of IPv4-embeded IPv6 address
than just using it to obey a constraint whose future usage is still
uncertain. That is to say, the IPv4-embeded IPv6 addresses can be identified
by some bits (e.g. the binary value of bit 64 to 66 is a specific value,
which is not conflicted with any used OUIs). Furthermore, different types
can also be distinguished by the remaining bits for that octet (e.g., bit 67
to 71).

At least the former usage has some certain applications. For example, in
case of NAT64, if a dual-stack host could distinguish synthesized IPv6
addresses from native IPv6 addresses, it will not prefer a synthesized IPv6
address to an IPv4 address for initiating a communication with an IPv4 host.
Another usage is to avoid routing loops when using ISATAP and 6to4 (for more
details, please see
http://www.ietf.org/proceedings/09nov/slides/v6ops-2.ppt).

Xiaohu

---

From: Rémi Després <[email-masked]>
Date: Wed, 09 Dec 2009 10:08:01 +0100

Christian Huitema wrote :
> Xu Xiaohu wrote :

>> IPv4-embeded IPv6 addresses has been removed, just as what we are
>> now doing on SIIT. (E.g., replacing the IPv4-Compatible IPv6
>> Address and IPv4-Mapped IPv6 Address with IPv4-translatable IPv6
>> address and IPv4-converted IPv6 address respectively).

This may be possible then... or not (one never knows).
To avoid unnecessary discussions, it is IMHO wiser not to try to decide
anything about this now.

> Any revision of the IPv6 addressing rules in 6MAN is going to take a
> long time. Maybe several years.

Doing better should be a goal, at least to reach consensus.
This discussion started long ago, but so far without real attempts to 
reach conclusion.
It seems to be the time do deal with it.

Christian, as you are one of those who have lived the early history of
IPv6, do you know any *technical objection*, from any one, for the 
following which, as new address formats are and will be defined, should 
be more appropriate than the current text:

"For all unicast addresses other than those that start with the
binary value 000, and that are used as destinations on IPv6 links having
/64 subnet prefixes, Interface IDs are required to be constructed in
Modified EUI-64 format.
If new formats are defined in the future for such Interface IDs, they
must be distinguishable from the Modified EUI-64 format, i.e. must
have their two lower bits of the first octet both set to 1"

> I would rather not wait that long before we publish the addressing
> format document.

Agreed.

> Beside, complying with the rule is not that hard. So
> why bother?

Bothering about this question now is better to avoid coming back to the 
same subject over and over again, and to permit simpler designs in the 
future.

Regards,

RD

---

From: Rémi Després <[email-masked]>
Date: Wed, 09 Dec 2009 11:06:07 +0100

Xu Xiaohu wrote :

> 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.
> 
> 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.

Two points:

1.
This sentence doesn't concern addresses that, like IPv4-mappable
addresses, are never subject to any neighbor discovery protocol.

2.
Relevance of this sentence seems negated in RFC 2462 where, in the
specification of IPv6 stateless autoconfiguration, we have (upper cases
added):

"To insure that all configured addresses are likely to be unique on a
given link, NODES RUN a "duplicate address detection" algorithm on
addresses before assigning them to an interface.  The Duplicate ddress
Detection algorithm is performed on ALL addresses, independent of
whether they are obtained via stateless or stateful autoconfiguration."

Indeed, not checking uniqueness of IPv6 addresses when they are
MAC-address derived would be a bad idea: MAC addresses cannot be assumed
to be really universal because they can be administratively configured
in some hosts.

> Look forward to a clear conclusion after discussing it in the 6man 
> mailing-list.

Agreed.

Best regards,

RD

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Wed, 9 Dec 2009 12:00:04 +0100

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Rémi Després
> Sent: 09 December 2009 11:06
> To: Xu Xiaohu
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; 'Brian E Carpenter'; [email-masked]
> Subject: Re: [BEHAVE] address-format: bits 64 to 71
> 
> Xu Xiaohu wrote :
> 
> This sentence doesn't concern addresses that, like 
> IPv4-mappable addresses, are never subject to any neighbor 
> discovery protocol.
> 
> 
> 2.
> Relevance of this sentence seems negated in RFC 2462 where, 
> in the specification of IPv6 stateless autoconfiguration, we 
> have (upper cases
> added):
> 
> "To insure that all configured addresses are likely to be 
> unique on a given link, NODES RUN a "duplicate address 
> detection" algorithm on addresses before assigning them to an 
> interface.  The Duplicate ddress Detection algorithm is 
> performed on ALL addresses, independent of whether they are 
> obtained via stateless or stateful autoconfiguration."
> 
> Indeed, not checking uniqueness of IPv6 addresses when they 
> are MAC-address derived would be a bad idea: MAC addresses 
> cannot be assumed to be really universal because they can be 
> administratively configured in some hosts.

Under the EUI-64 scheme, a non unique IPv6 address is the result of a non-unique MAC address. When having the latter in a shared bridge domain is a bit of a problem to say the least and doing or not doing IPv6 DAD doesn't change things. Where checking for uniquness makes sense is whenever there is some involvment of randomness or administrative fiat in configuring/creating the IPv6 address. Hence in a perfect world where the EUI-64 interface-id rules apply, checking for uniquness wouldn't be needed. In mandating the check the authors evidently thought of the cases where the EUI-64 rule doesn't hold.

-Woj.

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

---

From: Rémi Després <[email-masked]>
Date: Wed, 09 Dec 2009 13:41:17 +0100

Wojciech Dec (wdec) wrote:

>> MAC-address derived would be a bad idea: MAC addresses cannot be 
>> assumed to be really universal because they can be administratively
>>  configured in some hosts.
> 
> Under the EUI-64 scheme, a non unique IPv6 address is the result of a
>  non-unique MAC address. When having the latter in a shared bridge 
> domain is a bit of a problem to say the least and doing or not doing 
> IPv6 DAD doesn't change things.

Right: it's only where there is no shared bridge to detect the problem 
that the DAD is alone to do the job and, since hosts ignore whether 
there is such a bridge, it's logical that, as required by the 
introduction of RFC 2462, address uniqueness be always checked.

> Where checking for uniquness makes sense is whenever there is some
> involvment of randomness or administrative fiat in
> configuring/creating the IPv6 address.

> Hence in a perfect world where
> the EUI-64 interface-id rules apply, checking for uniquness wouldn't
> be needed. In mandating the check the authors evidently thought of
> the cases where the EUI-64 rule doesn't hold.

Yes.
To be on the safe side in the real world, they were right to do so .

RD

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 09 Dec 2009 14:24:27 +0100

> The well known prefix is easy to recognize, so there is no problem there. For stateless, the design makes sure that the IPv4 translatable addresses can be routed natively, which means there is no r…
In addition, in the NSP case, the host can configure the RFC3484 policy 
table to preffer native connectivity.

Regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 09 Dec 2009 14:26:19 +0100

> Any revision of the IPv6 addressing rules in 6MAN is going to take a long time. Maybe several years. I would rather not wait that long before we publish the addressing format document. Beside, comp…

fully agree.

We have discussed this issue before.
The conclusion in behave was AFAICT: " go to 6man, disucss there and we 
will do whatever 6man decides"
So far, AFAIU, 6man has not updated the IPv6 address architecture, so 
the reasonable thing to do in behave is to honour the current address 
architecture.

Regards, marcelo

---

From: Christian Huitema <[email-masked]>
Date: Wed, 9 Dec 2009 15:33:00 +0000

> /64 subnet prefixes, Interface IDs are required to be constructed in

First, let's have this discussion only in the 6MAN WG. The BEHAVE working group is supposed to deal with the network rules that we have, not try to change them.

The opening of the can of worms lies in your statement, "on IPv6 links having /64 subnet prefixes." We gained a lot of simplicity from having a simple subnet+host format. There have been discussions in the past of changing that, but these discussions always felled flat, since there is no obvious advantage to subnet prefixes larger than 64 bits. More precisely, the justification always seems to try avoid some administrative rule, but the rules are not linked to the specific number 64. They derive from tensions between users and providers, providers and regions, between providers themselves. Changing the boundary would not reduce the tensions, merely displace them. I would expect some very serious pushback.

Once you accept that you have a fixed boundary, then you realize that reusing an already existing allocation scheme is a very nice feature. The cost appears to be 2 bits out of 64, leaving 62 bits for innovative schemes. More than enough for any reasonable management system.

-- Christian Huitema

---

From: Rémi Després <[email-masked]>
Date: Wed, 09 Dec 2009 17:59:21 +0100

Christian Huitema a écrit :
> 
>> Christian, as you are one of those who have lived the early history
>>  of IPv6, do you know any *technical objection*, from any one, for 
>> the following which, as new address formats are and will be 
>> defined, should be more appropriate than the current text:
>> 
>> binary value 000, and that are used as destinations on IPv6 links 
>> having /64 subnet prefixes, Interface IDs are required to be 
>> constructed in Modified EUI-64 format.
> 
> First, let's have this discussion only in the 6MAN WG. The BEHAVE 
> working group is supposed to deal with the network rules that we 
> have, not try to change them.

Agreed, that's better.

> 
> The opening of the can of worms lies in your statement, "on IPv6 
> links having /64 subnet prefixes." We gained a lot of simplicity from
>  having a simple subnet+host format.

I appreciate this, in particular for the Neighbor Discovery protocol, a 
good design as far as I am concerned.
I don't suggest in any way that ND should work with other than /64 IIDs.
This sentence is IMO just a precise expression of the context in which 
the format constraint has been devised.
I would however have no objection to replacing "links having /64 subnet 
prefixes" by "links subject to the neighbor discovery protocol".
This, in my understanding, would avoid opening this can of worms.

> There have been discussions in the past of changing that, but these
> discussions always felled flat, since there is no obvious advantage
> to subnet prefixes larger than 64 bits. More precisely, the
> justification always seems to try avoid some administrative rule, but
> the rules are not linked to the specific number 64. They derive from
> tensions between users and providers, providers and regions, between
> providers themselves. Changing the boundary would not reduce the
> tensions, merely displace them. I would expect some very serious
> pushback.

See  above.

> Once you accept that you have a fixed boundary, then you realize that
>  reusing an already existing allocation scheme is a very nice
> feature. The cost appears to be 2 bits out of 64, leaving 62 bits for
>  innovative schemes. More than enough for any reasonable management 
> system.

The existing unnecessary complexity is for addresses that are never 
subject to ND.

Although I do agree that, to conclude quickly on IPv6 Addressing of 
IPv4/IPv6 Translators, the format of draft-ietf-behave-address-format-01 
section 2 should be adopted, it has to be faced that this format has 6 
sub-formats, because of the "u" bit constraint.

Without this constraint (unjustified so far) the format would have just 
been "prefix.v4(32).suffix", the suffix having possibly length zero.

This would have been a cleaner specification.

Unless you can come up with a real technical reason preventing such 
simplification in the future, or someone else, it's time IMO to clean up 
this unfortunate detail of the spec.

Regards,

RD

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 10 Dec 2009 09:22:03 +1300

On 2009-12-10 05:59, Rémi Després wrote:
>>> the following which, as new address formats are and will be defined,
>>> should be more appropriate than the current text:
>>>
>> working group is supposed to deal with the network rules that we have,
>> not try to change them.
> 
> Agreed, that's better.
> 
>>
>> The opening of the can of worms lies in your statement, "on IPv6 links
>> having /64 subnet prefixes." We gained a lot of simplicity from

Unfortunately, I don't think so. You have to consider the case of
address referrals. I don't know of any magic by which a third party
host (or application instance in a third party host, to be more precise)
would know by looking at an address that it belongs to a link subject
to the ND protocol. All it knows is that the address is, or is not,
a unicast address whose first three bits are 000.

So either we *do* keep the rule that in such addresses u/g is
valid, or we *don't* keep that rule. We can't make it conditional.

...
> this unfortunate detail of the spec.

It isn't unfortunate. It was actually intended to leave the door open
for 8+8 (as it was understood at the time), since 8+8 and GSE required
globally unique IIDs. Today's derivative of 8+8, ILNP, does *not* require
globally unique IIDs. But that decision in the ILNP design might itself
be contentious. I think we'd need some sort of community decision
about this whole topic before taking a decision about the u/g detail.

    Brian

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 10 Dec 2009 02:25:44 +0100

Xu Xiaohu escribió:
>> marcelo bagnulo braun
>> 发送时间: 2009年12月9日 21:24
>> 收件人: Christian Huitema
>> 抄送: [email-masked]; Xu Xiaohu; [email-masked]
>> 主题: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to apply to ALL
>>>> At least the former usage has some certain applications. For example,
>>>>         
> in
>   
>>>> addresses from native IPv6 addresses, it will not prefer a synthesized
>>>>         
> IPv6
>   
>>>> address to an IPv4 address for initiating a communication with an IPv4
>>>>         
> host.
>   
>>> The well known prefix is easy to recognize, so there is no problem
>>>       
> there.
>   
>> For stateless, the design makes sure that the IPv4 translatable addresses
>>     
> can
>   
>> be routed natively, which means there is no reason to not prefer them.
>>     
> That
>   
>> leaves a pretty small domain of applicability for any scheme that would
>>     
> reserve
>   
>> identifier patterns...
>>     
>>>       
> However, when one configures such a policy that native IPv6 connectivity
> should be preferred to IPv4 connectivity. How could the dual-stack host
> distinguish synthesized IPv6 addresses from native IPv6 addresses? If there
> are some bits to tell whether it is an IPv4-embeded IPv6 address or not
> (even which type of IPv4-embeded IPv6 address), the above issue can be
> solved easily.
>   
for the NSP, what the host needs to know is the NSP itself, that is what
needs to be included in the policy table

Regards, marcelo

---

From: Bob Hinden <[email-masked]>
Date: Wed, 9 Dec 2009 17:40:33 -0800

> Once you accept that you have a fixed boundary, then you realize that reusing an already existing allocation scheme is a very nice feature. The cost appears to be 2 bits out of 64, leaving 62 bits…

+1

Bob

---

From: Xu Xiaohu <[email-masked]>
Date: Thu, 10 Dec 2009 09:21:17 +0800

in
IPv6
host.
there.
can
That
reserve

Xiaohu

---

From: Xu Xiaohu <[email-masked]>
Date: Thu, 10 Dec 2009 09:35:50 +0800

> -----邮件原件-----
> 发件人: marcelo bagnulo braun [mailto:[email-masked]]
> 发送时间: 2009年12月10日 9:26
> 收件人: Xu Xiaohu
> 抄送: 'Christian Huitema'; [email-masked]; [email-masked]

Even so, if a dual-stack host obtains a synthesized IPv6 address as a
response to its DNS query for AAAA record at first, will it send a DNS query
for A record later due to the above policy table?

Xiaohu

---

From: Rémi Després <[email-masked]>
Date: Thu, 10 Dec 2009 15:25:23 +0100

> a unicast address whose first three bits are 000.

The important point is that AFAIK the third party doesn't need to know.
As long as the first part of the address referral can be routed, it can 
use it as destination, and leave the target network decide what to do.

For example, it isn't necessary in a source host, and in a source 
network, to recognize that a destination is an ISATAP address.
It is enough that the destination network, and destination host, 
recognize it.
We know, of course, that the ISATAP address format does comply with the 
"u" bit constraint, but AFAIK there is no *documented technical reason* 
why, today, this couldn't have been dispensed from.

> valid, or we *don't* keep that rule. We can't make it conditional.

Agreed, but in my understanding my proposal doesn't make it conditional.
It just restricts its scope.

> It isn't unfortunate. 

I don't mean unfortunate *when it was stated*, just unfortunate *now* 
(i.e. in a different context where more and more address fields, to be 
converted in some way to produce on-link addresses, are embedded in IPv6 
addresses.)

It was actually intended to leave the door open
> globally unique IIDs. 

Thanks for this reference.

Note that:
o draft-odell-8+8-00 has its unique End System Designators (ESDs) in the 
first 15 bits of the 9th and 10th address octets, and they provide "for 
32768 distinct partitions in the Private Topology". They may therefore 
have *any values* in "u" and "g" bits.
o draft-ietf-ipwng-gseaddr-00 distinguishes GSE addresses from others by 
a GSE-specific mark in the first bits of addresses. There is no need for 
any "u" bit to know that ESDs are globally unique.

Interesting, isn't it?

> Today's derivative of 8+8, ILNP, does *not* require
> globally unique IIDs. 

Good to be confirmed!

> But that decision in the ILNP design might itself
> be contentious. 

> I think we'd need some sort of community decision

Full agreement on this.
That's the purpose of contributing here.

Best regards,

RD

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 10 Dec 2009 16:41:04 +0100

Xu Xiaohu escribió:
>>>>>> case of NAT64, if a dual-stack host could distinguish synthesized
>>>>>>             
> IPv6
>   
>>>>>> addresses from native IPv6 addresses, it will not prefer a
>>>>>>             
> synthesized
>   
>>> IPv6
>>>
>>>       
>>>>>> address to an IPv4 address for initiating a communication with an
>>>>>>             
> IPv4
>   
>>> host.
>>>
>>>       
>>>> For stateless, the design makes sure that the IPv4 translatable
>>>>         
> addresses
>   
>>> can
>>>
>>>       
>>> distinguish synthesized IPv6 addresses from native IPv6 addresses? If
>>>       
> there
>   

mmm two comments about this.
First in general, except some rare excpetions, the dual stack hosts
should not have a dns64 capable server as their dns server, so in
general this should not happen
Second, you don't solve this problem by adding some bits in the middle
for recognizing the synthetic addresses. The point is that i am making
is that having them in the rpefix or in the iid achieve the same
capability (and have the same limitations)

Regards, marcelo

---

From: Xu Xiaohu <[email-masked]>
Date: Fri, 11 Dec 2009 17:43:14 +0800

> 发送时间: 2009年12月10日 23:41

Consider a scenario where dual-stack hosts coexist with IPv6 only hosts
(IPv6 only stack or dual-stack with only IPv6 address), should they be
configured with different DNS servers? That is to say, should dual-stack
hosts be configured with a normal DNS server, while IPv6 only hosts
configured with a DNS64 capable server?

Or do you believe the above scenario itself is rare?

> capability (and have the same limitations)

There seems no bit in a NSP to tell whether an IPv6 address is a synthetic
address or not in the current address-format draft. On the contrary, we
could use some bits in the IID to achieve that goal. 

Another possible way is as follows: the NSP used for synthesizing IPv6
address should be a specific prefix, e.g. starting with the binary value
00010101. In this way, the constraint on IID format mentioned before is
removed due to starting with the binary value 000. In addition, this address
is also provider aggregatable because the remaining part between the above
binary value and the last four octets (i.e., IPv4 address to be embedded) is
network specific.

Comments?

Best wishes,
Xiaohu

---

From: Xu Xiaohu <[email-masked]>
Date: Fri, 11 Dec 2009 17:58:58 +0800

> -----邮件原件-----
> 发件人: Rémi Després [mailto:[email-masked]]
> 发送时间: 2009年12月10日 22:25
> 收件人: Brian E Carpenter
> 抄送: Christian Huitema; [email-masked]; Xu Xiaohu

"ILNP requires that a Node ID is unique *within the context of a given
Locator*. ILNP does not require that a Node ID be globally unique."  This
statement is made by Ran, the major author of ILNP. Hence it seems that the
IID constrain is also not much useful for ILNP, IMHO.

For more details, please see the previous discussion thread:
http://www.ietf.org/mail-archive/web/rrg/current/msg05111.html

Best wishes,
Xiaohu

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 11 Dec 2009 21:56:51 +0100

Xu Xiaohu escribió:
>>>>>> 主题: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to apply to
>>>>>>             
> ALL
>   
>>>>>>>> At least the former usage has some certain applications. For
>>>>>>>>                 
> example,
>   
>>>>>>>>                 
>>>>> in
>>>>>
>>>>>
>>>>>           
>>>>>> be routed natively, which means there is no reason to not prefer
>>>>>>             
> them.
>   
>>>>>>             
>>>>> That
>>>>>
>>>>>
>>>>>           
>>>>>> leaves a pretty small domain of applicability for any scheme that
>>>>>>             
> would
>   
>>>>>>             
>>>>> reserve
>>>>>
>>>>>
>>>>>           
>>>>>> identifier patterns...
>>>>>>
>>>>>>
>>>>>> In addition, in the NSP case, the host can configure the RFC3484
>>>>>>             
> policy
>   
>>>>> However, when one configures such a policy that native IPv6
>>>>>           
> connectivity
>   
>>>>> should be preferred to IPv4 connectivity. How could the dual-stack
>>>>>           
> host
>   
>>>>> are some bits to tell whether it is an IPv4-embeded IPv6 address or
>>>>>           
> not
>   
>>>> for the NSP, what the host needs to know is the NSP itself, that is
>>>>         
> what
>   
>>> response to its DNS query for AAAA record at first, will it send a DNS
>>>       
> query
>   
> configured with different DNS servers? 
yes, that's how they should be configured. Please note that this does
not require two dns servers, you can run them in the same box as two
separate process, and use two different ip addresses. That would be the
best configuration (especially cause it would work with legacy nodes,
either dual stack or v6 only). (please note that other mechanisms
recognizing some bits, either the prefix or some bits in the iid would
require updating the node, and that is why this method is superior)

> That is to say, should dual-stack
> address or not in the current address-format draft.

the NSP itself is what needs to be learned by the hosts that want to
recognize a synthetic address!

I mean, in particular with the rfc3484 poilicy table, you need to
configure the NSP in the policy table, so that native connectivity is
preferred.

the main difference between this iand having a fix set of bits is that
these need to be learnt by the hosts in order to recognize the NSP. Note
that there is ongoing work to dynamically configure the rfc3484 policy
table, which would deal with this issue. Another option is to use the
WKP which can be hardcoded.
>  On the contrary, we
> 00010101. 
we have that, and that is the WKP

Regards, marcelo

> In this way, the constraint on IID format mentioned before is

---

From: Xu Xiaohu <[email-masked]>
Date: Mon, 14 Dec 2009 09:41:38 +0800

> require updating the node, and that is why this method is superior)

Can the DNS server be automatically configured according to whether the
client is dual-stack or not?  If not, I don't think this is the best choice.

> configure the NSP in the policy table, so that native connectivity is

If I understood it correctly, the basic precondition of this approach is the
NSP is known to the hosts in IPv6 realm. Hence, I wonder whether this
approach is still suitable for the IPv6 Internet to an IPv4 network scenario
where NSPs used by different IPv4 sites are much various.

> we have that, and that is the WKP

There are three choice for the WKP in the address-format draft:
   o  reuse the IPv4-mapped prefix, ::FFFF:0:0/96, as specified in RFC
      2765 Section 2.1;
   o  request IANA to allocate a /32 prefix,
   o  or request allocation of a new /96 prefix.

Could you tell me which one is equivalent to the specific NSP I mentioned,
which starts with a special binary value?

Best wishes,
Xiaohu

> > binary value and the last four octets (i.e., IPv4 address to be
embedded)
> is

---

From: GangChen <[email-masked]>
Date: Sun, 20 Dec 2009 21:28:07 +0800

> 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?)
>
> on. It may have no value in currently understood cases of 1:1 communication

I have a concern about that specified rule of "bits 64 to 71" doesn't
protect the semantics of the u/g bit. In the case of adopting WKP, the
U-bits should be 1, since WKP is only concatenated with global IPv4 address
to guarantee the uniqueness of IPv4-Converted IPv6 addresses. Following
statement is quoted from draft-ietf-bahave-address-format-03.

"When using a /96 prefix, the administrators MUST ensure that the bits 64 to
71 are set to zero."

If this rule is applied to WKP case, it might even break the semantics of
the u/g bit.

BRs

Gang

---

From: Christian Huitema <[email-masked]>
Date: Sun, 20 Dec 2009 16:59:44 +0000

> I have a concern about that specified rule of "bits 64 to 71" doesn't protect the semantics 
> of the u/g bit. In the case of adopting WKP, the U-bits should be 1, since WKP is only 
> concatenated with global IPv4 address to guarantee the uniqueness of IPv4-Converted 
> IPv6 addresses. Following statement is quoted from draft-ietf-bahave-address-format-03.
> 
> "When using a /96 prefix, the administrators MUST ensure that the bits 64 to 71 are set to zero."
> 
> If this rule is applied to WKP case, it might even break the semantics of the u/g bit.

No.

The "uniqueness" property is defined as "guaranteed to not collide with an IEEE802 identifier." IPv4 addresses do not have that property.

Besides, the WKP prefix (64:FF9B::/96) falls in the ::/8 range reserved for the IETF, the only range in which the U/G requirements do not apply.

-- Christian Huitema

---

From: GangChen <[email-masked]>
Date: Mon, 21 Dec 2009 14:56:23 +0800

>
>
>
> No.
>
> The "uniqueness" property is defined as "guaranteed to not collide with an
> IEEE802 identifier." IPv4 addresses do not have that property.
>
> Besides, the WKP prefix (64:FF9B::/96) falls in the ::/8 range reserved for
> the IETF, the only range in which the U/G requirements do not apply.
>

Thanks for the clarification.

If WKP(64:FF9B::/96) is the consensus, it better to state clearly that WKP
should not apply U/G requirements in the draft, right?

Especially, in the section 2 "When using a /96 prefix, the administrators
MUST ensure that the bits 64 to 71 are set to zero."

How about this:  "When using a /96 prefix, except the WKP that start with
the binary
   value 000, the administrators MUST ensure that the bits 64 to 71 are set
to zero."

It's more clear.

BRs

Gang

---

From: Christian Huitema <[email-masked]>
Date: Mon, 21 Dec 2009 15:24:34 +0000

> If WKP(64:FF9B::/96) is the consensus, it better to state clearly that WKP should not apply U/G requirements in the 
> draft, right?

The U/G bits in 64:FF9B::/96 are set to zero, so there is no need for an exception.

> How about this:  "When using a /96 prefix, except the WKP that start with the binary
> value 000, the administrators MUST ensure that the bits 64 to 71 are set to zero."
 
Except this requirement applies to "administrators", who cannot legitimately obtain a prefix in ::/8. These prefixes can only be defined by IETF action.

-- Christian Huitema

---

From: GangChen <[email-masked]>
Date: Tue, 22 Dec 2009 00:36:43 +0800

2009/12/21 Christian Huitema <[email-masked]>

> > If WKP(64:FF9B::/96) is the consensus, it better to state clearly that
> WKP should not apply U/G requirements in the
> > draft, right?
>

This is not an exception. This is a right way to compatible with RFC4291.
There are no restrains to set U/G bits in 64:FF9B::/96 to zero. We even
could set U/G bit to 1, as long as WKP maintains checksum neutral.

> Except this requirement applies to "administrators", who cannot
> legitimately obtain a prefix in ::/8. These prefixes can only be defined by
> IETF action.
>

Does this requirement only apply to the NSP that administrators can
legitimately obtain
?

--Gang