Subject: [BEHAVE] address-format: null suffix, consensus check

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

Hi, All,

In the draft-ietf-behave-address-format-01.txt, the document reads:

When a /32 prefix is used, the null suffix results in a null
identifier. We understand the conflict with Section 2.6.1 of
RFC4291, which specifies that all zeroes are used for the subnet-
router anycast address. However, in our specification, there would
be only one IPv4 translatable host in the /64 subnet, and the anycast
semantic would not create confusion. We thus decided to keep the
null suffix for now. (Different authors of this document have
different opinions.)

An example which support the above argument is presented in page 18 of
http://www.ietf.org/proceedings/09nov/slides/behave-5.ppt

Please confirm if we should keep the current conclusion.

Regards,

xing

---

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

I actually changed that text in the rev2 draft. The last text says:

   When a /32 prefix is used, an all-zero suffix results in an all-zero
   interface identifier.  We understand the conflict with Section 2.6.1
   of RFC4291, which specifies that all zeroes are used for the subnet-
   router anycast address.  However, in our specification, there would
   be only one IPv4 translatable host in the /64 subnet, and the anycast
   semantic would not create confusion.  We thus decided to keep the
   null suffix for now.  (This issue does not exist for prefixes larger
   than 32 bits, such as the /40, /56 and /64 prefixes that we recommend
   in section 3.3.)

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

Hi, All,

Regards,

xing

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

---

From: Xing Li <[email-masked]>
Date: Mon, 07 Dec 2009 07:33:26 +0800

>    than 32 bits, such as the /40, /56 and /64 prefixes that we recommend

Agree. Thanks. xing

---

From: <[email-masked]>
Date: Mon, 7 Dec 2009 18:06:47 +0100

Hello,
 
If i truly understand the slides the scope of the document is covering both:
"IPv4 translatable" IPv6 address
"IPv4 converted" IPv6 address.
 
In slide 4 you say that both must use the same prefix and I agree.
 
But in my humble opinion there is no need to have the same suffix requirement for all different cases.
For "IPv4 converted" IPv6 address used by a NAT64 the null suffix is a good solution.
 
But as "IPv4 translatable" IPv6 addresses are assigned to a IPv6 hosts, such IPv6 address can be assigned on a local network to an host that is not a routers but a simple end host. In such case, it may be interesting to use the most significant part of the IPv6 address as local network prefix (usually a /64 prefix). In that case the least significant part of the address is not the Ethernet interface address (U=0) but in accordance with RFC4291 this part may be used with the link local prefix instead of the local network prefix. But if the suffix is 0 this address is not unique on the local network. This problem can be solved by copying the part of the IPv4 address that is in the prefix (in the 64 most significant bit) in the suffix and adding a 24 bit long host identifier if the IPv4 address is not unique. I suggest to put the redundant part of the IPv4 address in the lest significant bit and the host identifier between the non redundant part of IPv4 address and the redundant part so that the host identifier can be used also as sub-network identifier to route the packet toward the appropriate host if needed.
 
Example :
 
    +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
    |PLEN| 0-------------32--40--48--56--64--72--80--88--96--104-112-120-127
    +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
    |/32 |     prefix    |v4(32)         | u |   Host ID |     V4 (32)   |
    +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
    |/40 |     prefix        |v4(24)     | u |(8)|  Host ID  | V4 (24)   |
    +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
    |/48 |     prefix            |v4(16) | u | (16)  | Host ID   |V4 (16)|
    +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
    |/56 |     prefix                |(8)| u |  v4(24)   | Host ID   |(8)|
    +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
    |/64 |     prefix                    | u |   v4(32)      | Host ID   |
    +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
    |/96 |     prefix                                    |   v4(32)      |
    +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

So for "IPv4 converted" IPv6 address used with a NAT64 translator the suffix should be 0.
But for "IPv4 translatable" address I think that the choice of the suffix must be open and must be chosen according the "IPv4 translatable" address usage.
 
Having different suffix value may be helpful, it can be used in a referral to distinguish an "IPv4 converted" IPv6 address from an "IPv4 translatable" address if the length of the prefix is known and different from /96 (this is needed to extract the IPv4 address from the format).
 
Best regards,

            Eric BURGEY
            Orange Labs
 
-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Xing Li
Envoyé : dimanche 6 décembre 2009 10:59
À : 'Behave WG'; Behave Chairs
Objet : [BEHAVE] address-format: null suffix, consensus check
 
Hi, All,

 

Regards,
 
xing

---

From: Christian Huitema <[email-masked]>
Date: Mon, 7 Dec 2009 18:52:15 +0000

Eric,

We did consider this type of design before writing the current proposal. For example, one proposal was to always copy the IPv4 address in bits 96-127 of the embedded address, even if that copy was a duplicate. That proposal was discarded for two reasons:

1) Duplicating data is generally a bad idea, as it forces the translators to deal with a new class or errors, when the supposedly duplicated values don't match.

2) Using the bits rather than reserving them precludes future extensions, and we are not certain enough of our choices to want to do that.

Note that administrators who want the addresses copied in the last bits can achieve that by selecting the /96 prefix of their choice. Administrators who want fine grain control on the mappings can also statically configure stateful mappings for some IPv4/IPv6 pairs, much like the "DMZ mapping" functions of the current crop of NAT44.

-- Christian Huitema

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, December 07, 2009 9:07 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [BEHAVE] address-format: null suffix, consensus check

Hello,

Example :

Best regards,

		Eric BURGEY
            Orange Labs

-----Message d'origine-----

Hi, All,

Regards,

xing

---

From: Xu Xiaohu <[email-masked]>
Date: Tue, 08 Dec 2009 16:54:16 +0800

> -----邮件原件-----
> 发件人: [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
> 
> Eric,
> 
> We did consider this type of design before writing the current proposal. For
> example, one proposal was to always copy the IPv4 address in bits 96-127 of
> the embedded address, even if that copy was a duplicate. That proposal was
> discarded for two reasons:
> 
> 1) Duplicating data is generally a bad idea, as it forces the translators to
> deal with a new class or errors, when the supposedly duplicated values don't
> match.
> 
> 2) Using the bits rather than reserving them precludes future extensions, and
> we are not certain enough of our choices to want to do that.
> 
> Note that administrators who want the addresses copied in the last bits can
> achieve that by selecting the /96 prefix of their choice. Administrators who
> want fine grain control on the mappings can also statically configure stateful
> mappings for some IPv4/IPv6 pairs, much like the "DMZ mapping" functions of
> the current crop of NAT44.

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

Xiaohu

> But as "IPv4 translatable" IPv6 addresses are assigned to a IPv6 hosts, such
> IPv6 address can be assigned on a local network to an host that is not a routers
> but a simple end host. In such case, it may be interesting to use the most
> significant part of the IPv6 address as local network prefix (usually a /64
> prefix). In that case the least significant part of the address is not the
> Ethernet interface address (U=0) but in accordance with RFC4291 this part may
> be used with the link local prefix instead of the local network prefix. But
> if the suffix is 0 this address is not unique on the local network. This problem
> can be solved by copying the part of the IPv4 address that is in the prefix
> (in the 64 most significant bit) in the suffix and adding a 24 bit long host
> identifier if the IPv4 address is not unique. I suggest to put the redundant
> part of the IPv4 address in the lest significant bit and the host identifier
> between the non redundant part of IPv4 address and the redundant part so that
> the host identifier can be used also as sub-network identifier to route the
> packet toward the appropriate host if needed.
> 
> Example :
> 
>     |PLEN|
> 0-------------32--40--48--56--64--72--80--88--96--104-112-120-127
> But for "IPv4 translatable" address I think that the choice of the suffix must
> be open and must be chosen according the "IPv4 translatable" address usage.
> 
> Having different suffix value may be helpful, it can be used in a referral to
> distinguish an "IPv4 converted" IPv6 address from an "IPv4 translatable"
> address if the length of the prefix is known and different from /96 (this is
> needed to extract the IPv4 address from the format).
> 
> Best regards,
> 
> 
> 		Eric BURGEY
>             Orange Labs
>

---

From: <[email-masked]>
Date: Tue, 8 Dec 2009 10:31:14 +0100

Hello Christian,

I fully agree with you for addresses allocated to state-full translators like NAT64. 
For load balancing and resilience an operator may need to have more than one translators (usually 2, located in different area for security consideration) synchronized and able to serve the same customers. 
In my humble opinion suffix should be 0 because this address is really an anycast address representing the sub-network of all synchronized translators (2 in my example) sharing the same states and serving the same customers.

But the problem I want to raise is different and specific to some stateless translator. So I will give an example:

If an operator want to migrate the network toward a pure Pv6 network (for example to solve problem of overlapping private IPv4 address plan, the operator of a corporate network may migrate to a pure IPv6 addressing plan). But this operator needs to install a web server on this network with a public IPv4 address so that it can be reached also by IPv4 users through state-less translator. So what is the best translatable IPv6 address for this IPv4/IPv6 web server ?

*	Is it a translatable IPv6 address with a null suffix and a /96 prefix, but routing /96 prefix in the corporate network is heavy?

*	Is it a translatable IPv6 address with a null suffix and a prefix shorter than 64, but the link local prefix cannot be used for local management?

*	Is it a the IPv6 6RD address format described in  http://tools.ietf.org/html/draft-ietf-softwire-ipv6-6rd-01  but this format is designed to allocate IPv6 addresses to IPv4 host and not for IPv4 hosts on IPv6 network ?

Best regards.

	Eric BURGEY 

-----Message d'origine-----
De : Christian Huitema [mailto:[email-masked]] 
Envoyé : lundi 7 décembre 2009 19:52
À : BURGEY Eric RD-CORE-ISS; [email-masked]; [email-masked]; [email-masked]
Objet : RE: [BEHAVE] address-format: null suffix, consensus check

Eric,

-- Christian Huitema

Hello,

Example :

Best regards,

		Eric BURGEY
            Orange Labs

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Xing Li
Envoyé : dimanche 6 décembre 2009 10:59
À : 'Behave WG'; Behave Chairs
Objet : [BEHAVE] address-format: null suffix, consensus check

Hi, All,

Regards,

xing

---

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: Xing Li <[email-masked]>
Date: Tue, 08 Dec 2009 22:05:34 +0800

> Note that administrators who want the addresses copied in the last bits can achieve that by selecting the /96 prefix of their choice. Administrators who want fine grain control on the mappings can…

Agree. xing

---

From: Xing Li <[email-masked]>
Date: Tue, 08 Dec 2009 22:04:09 +0800

[email-masked] 写道:
> But as "IPv4 translatable" IPv6 addresses are assigned to a IPv6 
> hosts, such IPv6 address can be assigned on a local network to an host 
> that is not a routers but a simple end host. In such case, it may be 
> interesting to use the most significant part of the IPv6 address as 
> local network prefix (usually a /64 prefix). In that case the least 
> significant part of the address is not the Ethernet interface address 
> (U=0) but in accordance with RFC4291 this part may be used with the 
> link local prefix instead of the local network prefix. But if the 
> suffix is 0 this address is not unique on the local network. This 
> problem can be solved by copying the part of the IPv4 address that is 
> in the prefix (in the 64 most significant bit) in the suffix and 
> adding a 24 bit long host identifier if the IPv4 address is not 
> unique. I suggest to put the redundant part of the IPv4 address in the 
> lest significant bit and the host identifier between the non redundant 
> part of IPv4 address and the redundant part so that the host 
> identifier can be used also as sub-network identifier to route the 
> But for "IPv4 translatable" address I think that the choice of the 
> suffix must be open and must be chosen according the "IPv4 
> translatable" address usage.
>

Then this will cause the referral problem again, similar to the one when 
IPv4-translatable address and IPv4-converted address are using different 
prefixes. The details of the discussion can be found in 
http://www.ietf.org/proceedings/75/slides/behave-11.pdf.

regards,

xing

> Having different suffix value may be helpful, it can be used in a 
> referral to distinguish an "IPv4 converted" IPv6 address from an "IPv4 
> translatable" address if the length of the prefix is known and 
> different from /96 (this is needed to extract the IPv4 address from 
> the format).
>
> Best regards,
>
> Eric BURGEY
>
> Orange Labs
>
> ------------------------------------------------------------------------
>

---

From: Christian Huitema <[email-masked]>
Date: Tue, 8 Dec 2009 15:42:10 +0000

In practice, the "web server" that you describe is not a single server, but a set of servers managed by some load balancing system. We can speculate about the best way to manage that, but it would be nice to get actual implementation reports, including the load balancing aspects.

From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, December 08, 2009 1:31 AM
To: Christian Huitema; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [BEHAVE] address-format: null suffix, consensus check

Hello Christian,

Best regards.

        Eric BURGEY

-----Message d'origine-----
De : Christian Huitema [mailto:[email-masked]]
Envoyé : lundi 7 décembre 2009 19:52
À : BURGEY Eric RD-CORE-ISS; [email-masked]; [email-masked]; [email-masked]
Objet : RE: [BEHAVE] address-format: null suffix, consensus check

Eric,

-- Christian Huitema

Hello,

Example :

    |/96 |     prefix                                    |   v4(32)      |

Best regards,

                Eric BURGEY

            Orange Labs

-----Message d'origine-----

Hi, All,

different opinions.)

Regards,

xing

Behave mailing list

[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 09 Dec 2009 10:39:33 +1300

>> 主题: Re: [BEHAVE] address-format: null suffix, consensus check

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

I thought we'd discussed that a lot. Maybe it was not on the BEHAVE list.

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.

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

    Brian

---

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

Brian
> E Carpenter
> 发送时间: 2009年12月9日 5:40
> 收件人: Xu Xiaohu
> 抄送: [email-masked]; [email-masked]; [email-masked]
> 主题: [BEHAVE] address-format: bits 64 to 71
> 
> > 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?)
> 

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.

> via a NAT64, but we don't know where it might be important in p2p
communications,

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

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

> question to be resolved.)

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

Xiaohu

---

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

> IPv6 Address with IPv4-translatable IPv6 address and IPv4-converted IPv6

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: 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: Christian Huitema <[email-masked]>
Date: Wed, 9 Dec 2009 05:20:27 +0000

> 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: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Tue, 8 Dec 2009 22:37:07 -0800

General Comments
Overall, the document is in  a good shape and is ready for last call.
Some general comments/behavior.
1. An example flow either in sections 2 & 3 or in the appendix would
help understand the translation
process easily. I believe something like this was in the initial ivi
document.

Abstract:
Paragraph starting "Significant issues exist..."

I don't know what issues are being referred to here but there is no
description of the issues nor there is a pointer to a document that
describes/addresses the issues. I think we should either drop this
paragraph or describe the issues or point it to another relevant
document.
It is like saying "There are significant issues with stateful &
stateless modes, we wont tell you what they are but we don't plan to
address them in this document". That doesn't give me a good feeling when
I start to read this document.

Editorial comments.
1. Section 1.2 Para "The translating function specified in ..."

There is a reference to RFC2765 that is hanging here. I don't know what
is the intention of bringing in the reference without properly relating
it to the context.

2. Section 1.2 Para "Fragmented IPv4 UDP packet...."

"use over wide-areas in the Internet" - did you mean over wide-area
networks? If not, what does wide-areas mean here?

3. Section 1.4 Para 1.
s/must send packet to big/must send packet too big

4. Section 2
Para "However, when the IPv4 sender does..."

s/needed should the packet pass through an IP/ICMP translator/needed
should the packet pass through another IP/ICMP translator

5.Section 2.1 

Para 1 ".....IPv4 packet MUST be fragmented prior to translating it."

Why is this a MUST? Isnt this upto the implementation? How can you
verify the conformance?
How can you detect if the nat64 device fragments it and translates it or
translates it and fragments it?

6. Section 2.1 
Hop Limit: I think the recommendation should be to decrement the TTL and
send ICMP TTL exceeded before translation. Translating the packet and
decrementing TTL to find out the TTL expired and restoring the packet to
its original form seems to be unnecessarily complicating things. We
shouldn't even suggest that.

7. Section 2.2 
Para 2 "When a stateless translator...."
The text says "translator SHOULD drop the packet and generate a system
management
   event specifying at least"

Is the SHOULD for dropping the packet and generating the event? I think
generating the event should be optional/MAY.

8. Section 3.1
Time to Live - Same comment as hoplimit for IPv6.

9. Section 5 - Security considerations.
This document does not address any potential issues that might arise by
extracting a IPv4 address from the IPv6 address - particularly addresses
like broadcast or loopback addresses etc. I think adding some text
around that might be of help.

Senthil

---

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: 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:18:14 +0100

Christian Huitema escribió:
> Eric,
>
> We did consider this type of design before writing the current proposal. For example, one proposal was to always copy the IPv4 address in bits 96-127 of the embedded address, even if that copy was a duplicate.

FWIW, the proposal of embedding the IPv4 address twice int he IPv6 
address was discussed at rhe hiroshima meeting (on the context of 
decimal representations) and the chairs took a consensus check on this 
issue in the hiroshima meeting  and there was a strong consensus agaisnt 
it, as far as i recall.

Regards, marcelo

>  That proposal was discarded for two reasons:
>

---

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

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

---

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

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

---

From: Dave Thaler <[email-masked]>
Date: Thu, 10 Dec 2009 00:35:50 +0000

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Christian Huitema
> Sent: Sunday, December 06, 2009 10:24 AM
> To: Xing Li; 'Behave WG'; Behave Chairs
>    be only one IPv4 translatable host in the /64 subnet, and the

s/host/node/

It's not relevant whether there's only one "host" in the /64 subnet.
What's relevant is whether there's only one *node* in the /64 subnet
(a router is a node but not a host).

> anycast

---

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

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

Xiaohu

---

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

Xu Xiaohu escribió:
>>>> 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.
>   
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: 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: <[email-masked]>
Date: Thu, 10 Dec 2009 11:02:34 +0100

Hello,
I have a question about this IPv4 translatable IPv6 address:
Is possible to use this address on a real node interface or is just the IPv6 address of a virtual interface ?

If it is just for virtual interfaces, it is not really one node in the subnet but just one virtual interface in a virtual subnet inside a node connected to the real network through a different global unicast IPv6 address and acting as router toward this virtual subnet and i fully support the proposed format.

If it can assign to a real interface, the proposed sentence means that this interface must be the only one interface on the link, so it means that it is a point to point link. I have the feeling that it is a little bit too much restrictive. 
An alternative solution may be to write that this format is reserved for virtual interface and that, if there is a need to allocate an IPv4 translatable IPv6 to a real interface, another suffix value may be considered.

Best regards

	Eric BURGEY

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Dave Thaler
Envoyé : jeudi 10 décembre 2009 01:36
À : Christian Huitema; Xing Li; 'Behave WG'; Behave Chairs
Objet : Re: [BEHAVE] address-format: null suffix, consensus check

s/host/node/

> Behalf Of Xing Li

---

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: Dave Thaler <[email-masked]>
Date: Thu, 10 Dec 2009 21:11:17 +0000

> Sent: Thursday, December 10, 2009 2:03 AM
> To: Dave Thaler; Christian Huitema; [email-masked]; [email-masked]

IPv4-translatable addresses should be usable on regular interfaces.
However, I don't believe the text about null suffix should apply to
IPv4 translatable addresses, only IPv4 converted addresses, for
exactly the reason you mention.

-Dave

> 
> If it is just for virtual interfaces, it is not really one node in the
> subnet but just one virtual interface in a virtual subnet inside a node
> connected to the real network through a different global unicast IPv6
> address and acting as router toward this virtual subnet and i fully
> support the proposed format.
> 
> If it can assign to a real interface, the proposed sentence means that
> this interface must be the only one interface on the link, so it means
> that it is a point to point link. I have the feeling that it is a
> little bit too much restrictive.
> An alternative solution may be to write that this format is reserved
> for virtual interface and that, if there is a need to allocate an IPv4
> translatable IPv6 to a real interface, another suffix value may be
> considered.
> 
> Best regards
> 
> 	Eric BURGEY
> 
>

---

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: 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: Christian Huitema <[email-masked]>
Date: Mon, 14 Dec 2009 05:02:26 +0000

> which starts with a special binary value?

I just submitted an update to the address format draft: 
http://www.ietf.org/internet-drafts/draft-ietf-behave-address-format-02.txt
In draft-02, we propose to use the Well Known Prefix 64:FF9B::/96.

-- Christian Huitema

---

From: Xu Xiaohu <[email-masked]>
Date: Mon, 14 Dec 2009 16:45:08 +0800

> 发送时间: 2009年12月14日 13:02
> 收件人: Xu Xiaohu; 'marcelo bagnulo braun'
> 抄送: [email-masked]

"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". However, the specific NSP starting with a special
binary value (depicted as follows) could be used in the above scenario since
the Network Specific Parts is topologically aggregatable. That is to say,
the specific NSP is a hybrid type of 96/ prefix which starts with a
well-known binary (e.g., 00010101) while the remaining part is network
specific.

+--------+--------------------------------+-----------------+
|00010101|Network Specific Parts (88 bits)|IPv4 addr (32bit)|
+--------+--------------------------------+-----------------+

Hence, the Well Known Prefix 64:FF9B::/96 is not equivalent to the specific
NSP I mentioned. 

Xiaohu

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 14 Dec 2009 13:28:51 +0100

Xu Xiaohu escribió:
>>> Could you tell me which one is equivalent to the specific NSP I
>>>       
> mentioned,
>   
Maybe i am not understanding what you have in mind.
Could you put an concrete example of a scenario involving the IPv6
internet that requires the host to distinguish that the address of its
peer is synthetic?

Regards, marcelo

---

From: Xing Li <[email-masked]>
Date: Mon, 14 Dec 2009 22:28:02 +0800

Thanks. We will make modifications in the next version. xing

---

From: Xing Li <[email-masked]>
Date: Wed, 16 Dec 2009 21:39:26 +0800

Hi, Senthil,

Thanks for the review.

> process easily. I believe something like this was in the initial ivi

The IVI reference will be added.
> I start to read this document.

Deleted.

> is the intention of bringing in the reference without properly relating
Modified. (same as in [RFC2765]).

> networks? If not, what does wide-areas mean here?

wide-area deleted.
> s/must send packet to big/must send packet too big

Corrected.

> should the packet pass through another IP/ICMP translator

I think we still mean this IP/ICMP translator.

> translates it and fragments it?

This is discussed in para

However, when the IPv4 sender does not set the DF bit, the translator
has to ensure that the packet does not exceed the path MTU on the
IPv6 side. This is done by fragmenting the IPv4 packet so that it
fits in 1280 byte IPv6 packets, since that is the minimum IPv6 packet
size.

> shouldn't even suggest that.

We think this leaves the space for different implementation. The text is 
from the RFC2765. If the consensus is there, we are fine to make the 
modification.

> generating the event should be optional/MAY.

Again, this is from RFC2765. Any comments from the WG?

> Time to Live - Same comment as hoplimit for IPv6.

The same question to the WG.

> around that might be of help.

How about adding:

There are potential issues that might arise by extracting a IPv4 address 
from the IPv6 address - particularly addresses like broadcast or 
loopback addresses and the non IPv4-translatable IPv6 addresses, etc. 
Special action SHOULD be taken to avoid security problems.

Thanks.

xing

---

From: Xu Xiaohu <[email-masked]>
Date: Thu, 17 Dec 2009 15:14:45 +0800

> 发送时间: 2009年12月14日 20:29
> 抄送: 'Christian Huitema'; [email-masked]
> > "The Well-Known Prefix MUST NOT be used for scenario 3 (the IPv6
Internet
> to

                     +-------------------+
                     |                   |
   +-------------+   | IPv6 Internet     |   +--------------+
   |             +---+                   +--++---++ IPv4 only
   |Dual-stack   |   +-------------------+  |NAT64|         |
   | +-----+     |                          ++---++  +-----+|
   | | H1  |     |   +-------------------+   |       | H2  ||
   | +-----+     +---++                  +---+       +-----+|
   +-------------+   | IPv4 Internet     |   +--------------+
                     |                   |
                     +-------------------+

In the above scenario, after obtaining a synthesized IPv6 address of H2
(IPv4 host) through some way, H1 (dual-stack host) will initialize
communication to H2 using IPv6 since it could not identify whether the
resolved IPv6 address is synthetic or not. However, it's better to use IPv4
for the communication between them.

Does that make sense?

Xiaohu

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 17 Dec 2009 00:21:14 -0800

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Xu Xiaohu
> Sent: Wednesday, December 16, 2009 11:15 PM
> To: 'marcelo bagnulo braun'
> Cc: [email-masked]
> Subject: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to 
> apply to ALL non-0::/3 IPv6 addresses ?
> 
> 
> 
> > -----邮件原件-----
> http://www.ietf.org/internet-drafts/draft-ietf-behave-address-
> format-02.tx
> > >> t
> > > an IPv4 network), as this would lead to using the 
> Well-Known Prefix with
> non
> > > binary value (depicted as follows) could be used in the 
> above scenario
> since
> > > the Network Specific Parts is topologically aggregatable. 
> That is to
> say,

That implies that H1 would prefer IPv4 over IPv6 if the
IPv6 address contains the "is_translated" bit pattern.

But I can draw another picture where it's better to use
IPv6 between them because of multiple NAT44's on the path:

                      +-------------------+
                      |                   |
    +-------------+   | IPv6 Internet     |   +--------------+
    |             +---+                   +--++---++ IPv4 only
    |Dual-stack   |   +-------------------+  |NAT64|         |
    | +-----+     |                          ++---++  +-----+|
    | | H1  |     |      +-------------+        |     | H2  ||
    | +-----+     +-NAT44+             +--NAT44-+     +-----+|
    +-------------+      |IPv4 Internet|        +------------+
                         |             |
                         +-------------+

which tells me that we need more complex rules in H1 to
identify this situation and decide the 'best' path.

Note the NAT64 might be stateless (and thus allow SCTP, among 
other things) whereas the NAT44's only understand TCP&UDP.  If
I want to use SCTP, the 'best' path is the top.  If I am running
a protocol that is sensitive to address family changes (such
as FTP and its PASV and EPSV), I would want to use the bottom
path (to stay all IPv4).

These kinds of complications are why many of us are interested
in the GROBJ effort and the GROBJ BoF in Hiroshima.  

-d

---

From: Xu Xiaohu <[email-masked]>
Date: Thu, 17 Dec 2009 17:37:55 +0800

> -----邮件原件-----
> 发件人: Dan Wing [mailto:[email-masked]]
> 发送时间: 2009年12月17日 16:21
> 收件人: 'Xu Xiaohu'; 'marcelo bagnulo braun'
> 抄送: [email-masked]

It's too complex. Before you choose to use IPv6, you would have to determine
the NAT64 is stateless. To make things simple, IMHO, it'd better that native
connectivity (even address-only translation) is ALWAYS preferred to address
family translation.

Xiaohu

---

From: <[email-masked]>
Date: Thu, 17 Dec 2009 11:39:20 +0100

Dear Xiaohu,

Please see inline.

Cheers
Med

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Xu Xiaohu
Envoyé : jeudi 17 décembre 2009 08:15
À : 'marcelo bagnulo braun'
Cc : [email-masked]
Objet : Re: [BEHAVE] Reason(s) for Modified EUI-64 format to apply to ALL non-0::/3 IPv6 addresses ?

[SNIP]

                     +-------------------+
                     |                   |

Does that make sense?

Med: This scenario is one of the motivations why we proposed the A64 record proposal (see: http://tools.ietf.org/html/draft-boucadair-behave-dns-a64-01) to offload the NAT64.

*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 17 Dec 2009 12:45:19 +0100

Xu Xiaohu escribió:
>> http://www.ietf.org/internet-drafts/draft-ietf-behave-address-format-02.tx
>>     
>>>> t
>>> an IPv4 network), as this would lead to using the Well-Known Prefix with
>>>       
> non
>   
>>> global IPv4 addresses". However, the specific NSP starting with a
>>>       
> special
>   
>>> binary value (depicted as follows) could be used in the above scenario
>>>       
> since
>   
>>> the Network Specific Parts is topologically aggregatable. That is to
>>>       
> say,
>   
>>> Hence, the Well Known Prefix 64:FF9B::/96 is not equivalent to the
>>>       
> specific
>   
>>> NSP I mentioned.
>>>
>>>       

i see the scenario now,

i used a similar argument for supporting the use of the Well know prefix
a while ago, and the arguments against this argument (by Dan, who wrote
then a draft about referals, correct me if i am wrong) was that there is
actual no applications that actually do that today and that the
reasonable thing to do for an app was to pass the ipv4 address and then
allow the receiving end to synthesize the IPv6 address if needed.

Regards, marcelo

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 18 Dec 2009 11:37:35 +1300

On 2009-12-17 22:37, Xu Xiaohu wrote:
...
> connectivity (even address-only translation) is ALWAYS preferred to address

Not if identifying native connectivity is itself complicated. And also,
this whole issue is an optimisation for a coexistence technique that
we all hope has a short (maybe ten years) lifetime.

>> in the GROBJ effort and the GROBJ BoF in Hiroshima.

Yes, but we have to admit that this pushes the problem
up to the transport layer or higher. And maybe some sort of
super-REAP that actually *measures* the best path will be the
answer there, or of course MPTCP that intrinsically optimises
traffic flow.

    Brian

---

From: Xu Xiaohu <[email-masked]>
Date: Fri, 18 Dec 2009 09:29:53 +0800

> 发送时间: 2009年12月17日 19:45

                      +-------------------+
                      |                   |
    +-------------+   | IPv6 Internet     |    +--------------+
    |             +---+                   +---++---++ IPv4 only
    | IPv6 only   |   +-------------------+   |NAT64|         |
    | +-----+     |                           ++---++  +-----+|
    | | H1  |     |    +-------------------+   |       | H2  ||
    | +-----+  NAT64?- +                   +---+       +-----+|
    +-------------+    | IPv4 Internet     |   +--------------+
                       |                   |
                       +-------------------+
If I understand your statement correctly, An IPv6 only site (e.g., left site
in the above figure) MUST have a connection to the IPv4 Internet via NAT64
in order to access hosts located in an IPv4 only site (e.g., right site in
the above figure). Besides, the IPv6 only host (e.g. H1) MUST be able to
synthesize IPv6 address by itself. If either of the above two conditions is
not satisfied, the communication between H1 and H2 is impossible.

Xiaohu

---

From: Xu Xiaohu <[email-masked]>
Date: Fri, 18 Dec 2009 09:33:36 +0800

> -----邮件原件-----
> 发件人: Brian E Carpenter [mailto:[email-masked]]
> 发送时间: 2009年12月18日 6:38
> 收件人: Xu Xiaohu
> 抄送: 'Dan Wing'; 'marcelo bagnulo braun'; [email-masked]

Could you give a concrete example where identifying native connectivity is
itself complicated?

Xiaohu

---

From: Xu Xiaohu <[email-masked]>
Date: Fri, 18 Dec 2009 09:54:33 +0800

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表 Xu
> Xiaohu
> 发送时间: 2009年12月18日 9:30
> 收件人: 'marcelo bagnulo braun'
> 抄送: [email-masked]
ALL
> > allow the receiving end to synthesize the IPv6 address if needed.

Oh, the second condition can also be replaced by synthesizing IPv6 address
on DNS64 server.

Then, what is the meaning of the IPv6 Internet to IPv4 network scenario?

Xiaohu

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 18 Dec 2009 16:31:21 +1300

> Could you give a concrete example where identifying native connectivity is

It doesn't seem safe to assume that just because a host has a global
IPv6 address and the correspondent has a global IPv6 address, there is
native connectivity between them. The running code examples of this
are for IPv4 - there are many scenarios where two non-RFC1918 addresses
can only communicate via NAT.

Basically I think that trying to deduce scope or address realm by
examining bits in an address is unsafe (in the general case).

    Brian

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 17 Dec 2009 19:34:24 -0800

> Sent: Thursday, December 17, 2009 5:30 PM
> > >>>> 主题: RE: [BEHAVE] Reason(s) for Modified EUI-64 format 
> to apply to
> ALL
> > >>>>>   o  reuse the IPv4-mapped prefix, ::FFFF:0:0/96, as 
> specified in
> RFC
> > >>>>>      2765 Section 2.1;
> Well-Known Prefix
> with
> > > resolved IPv6 address is synthetic or not. However, it's 
> better to use
> IPv4

Yep -- because IPv4-only applications don't know anything about IPv6 addresses
-- IPv4-only applications don't know how to parse IPv6 addresses, how to
include them in referrals, etc.

We won't have any influence on those IPv4-only applications that are already
written that can't parse IPv6 addresses and have no idea what to do with an
IPv6 address (e.g., IPv4-only applications inside of personal video recorders,
SIP phones, etc.).  Besides, if you give an IPv4-only host an IPv6 address, it
can't get to that IPv6 address; if the IPv4-only host is running Teredo or
ISATAP or its router is running 6to4, it isn't (strictly speaking) an
IPv4-"only" host -- the host (and its application) is capable of IPv6, too --
so it is effectively dual-stack.

We can provide guidance to applications that are evolving (adding features and
functions, including becoming more aware of IPv6 interworking).  That is the
hope of GROBJ, and the purpose of draft-wing-behave-learn-prefix and
draft-wing-v6ops-v6app-v4server.

-d

---

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

Brian
> E Carpenter
> 发送时间: 2009年12月18日 11:31
> 收件人: Xu Xiaohu
> 抄送: [email-masked]; 'Dan Wing'

I'm a bit confused. Could you list one scenario where two non-RFC1918
addresses can only communicate via NAT?

Xiaohu

---

From: Xu Xiaohu <[email-masked]>
Date: Fri, 18 Dec 2009 11:50:29 +0800

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表 Dan
> Wing
> 发送时间: 2009年12月18日 11:34
> ALLnon-0::/3 IPv6 addresses ?
> 
> 
> 

Note that H1 in the above scenario is IPv6 only, but not IPv4 only. Hence
I'm wondering whether the statement you made is relevant to the above
scenario.

Xiaohu

> SIP phones, etc.).  Besides, if you give an IPv4-only host an IPv6
address,
> it

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 18 Dec 2009 16:56:03 +1300

> addresses can only communicate via NAT?

Sure. Every company, and there are many, that runs globally unique
IPv4 addresses internally but does not route them across border routers
to the Internet, putting NAT at the border instead. In this
case the addresses look like global addresses but behave like
RFC1918 addresses.

(Of course, this mainly applies to companies old enough to have
their own PI space in IPv4. I used to work for one of them. )

   Brian

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 17 Dec 2009 19:59:46 -0800

> From: Xu Xiaohu [mailto:[email-masked]] 
> Sent: Thursday, December 17, 2009 7:50 PM
> To: 'Dan Wing'; 'marcelo bagnulo braun'
> Cc: [email-masked]
> Subject: re: [BEHAVE] Reason(s) for Modified EUI-64 format to 
> apply to ALLnon-0::/3 IPv6 addresses ?
> 
> 
> 
> > -----邮件原件-----

But H2 is IPv4-only.  But nobody can know how the
referral happened; the address referral may have come 
through H3, not shown in the diagram, which might itself 
be IPv4-only (that is, an IPv6-unaware version of this 
application that is sending referrals around.  For 
example, a SIP phone (Alice calls Bill which is forwarded
to Carol which is forwarded to Debbi) or an older 
version of a BitTorrent client that lacks IPv6 awareness 
/ support - and we know how torrent trackers share
things around all over the place).

-d

> > written that can't parse IPv6 addresses and have no idea 
> what to do with
> an
> > IPv4-"only" host -- the host (and its application) is 
> capable of IPv6, too
> --
> > We can provide guidance to applications that are evolving 
> (adding features
> and
> > functions, including becoming more aware of IPv6 
> interworking).  That is
> the

---

From: Xu Xiaohu <[email-masked]>
Date: Fri, 18 Dec 2009 14:19:18 +0800

> 发送时间: 2009年12月18日 11:50
> 收件人: 'Dan Wing'; 'marcelo bagnulo braun'
> 抄送: [email-masked]
Dan
> I'm wondering whether the statement you made is relevant to the above

Let me explain the scenario a bit more, in the above scenario, the
communication is initiated by H1 (IPv6 only host), but not H2 (IPv4 only
host). To make that communication possible, should a NAT64 be deployed
between the IPv6 only site (left site) and the IPv4 Internet although there
is already a NAT64 between the IPv4 site (right site) and the IPv6 Internet?
If so, what's the meaning of IPv6 Internet to IPv4 network scenario?

Xiaohu

> > IPv4-"only" host -- the host (and its application) is capable of IPv6,
too
> > We can provide guidance to applications that are evolving (adding
features

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 18 Dec 2009 00:49:37 -0800

> > > Yep -- because IPv4-only applications don't know anything 
> about IPv6
> > addresses

The "IPv6 Internet to IPv4 network" scenario applies to the ISP on the right.

Detail:

The ISP on the left is a business, and they made the decision to operate an
IPv6-only network with IPv6-only hosts. Their subscribers want access to
(and/or from) the IPv4 Internet, so that ISP provides a NAT64 (and associated
DNS64, of course).  This is the "an IPv6 network to the IPv4 Internet"
scenario (when the connection is initiated from the IPv6 host) and is the "the
IPv4 Internet to an IPv6 network" (when the connection is initiated from the
IPv4 side).  Note that a stateful NAT64 will generally not support "the IPv4
Internet to an IPv6 network" unless port mappings are configured on the
stateful NAT64.

The ISP on the right is another, separate business, and they made the decision
to keep their subscribers running IPv4.  Their subscribers want access to
(and/or from) the IPv6 Internet.  This is "an IPv4 network to the IPv6
Internet" (when the connection is initiated from the IPv4 side) and is "the
IPv6 Internet to an IPv4 network" (when the connection is initiated from the
IPv6 side).

-d

---

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Fri, 18 Dec 2009 11:26:04 -0800

-----Original Message-----
From: Xing Li [mailto:[email-masked]] 
Sent: Wednesday, December 16, 2009 8:39 AM
To: Senthil Sivakumar (ssenthil)
Cc: [email-masked]
Subject: Re: [BEHAVE] Comments on draft-ietf-behave-v6v4-xlate-04

Hi, Senthil,

Thanks for the review.

Senthil Sivakumar (ssenthil) 写道:
> help understand the translation process easily. I believe something 
> like this was in the initial ivi document.
>   

> address them in this document". That doesn't give me a good feeling 
> when I start to read this document.
>   

Deleted.

> There is a reference to RFC2765 that is hanging here. I don't know 
> what is the intention of bringing in the reference without properly 
> relating it to the context.
>   

wide-area deleted.

Corrected.

[Senthil] Maybe I am confused, what does this sentence mean
"That is needed should the packet pass through an IP/ICMP translator." The packet is already passing through this translator and hence adding a fragment header does not help this device. What I thought you meant was if the packet has to pass through another IP/ICMP translator, then that translator (translating back from v6->v4) knows it can fragment the packet. If that is not the intention, I don’t see what is the value add for this sentence.

> How can you detect if the nat64 device fragments it and translates it 
> or translates it and fragments it?
>   

However, when the IPv4 sender does not set the DF bit, the translator has to ensure that the packet does not exceed the path MTU on the
IPv6 side. This is done by fragmenting the IPv4 packet so that it fits in 1280 byte IPv6 packets, since that is the minimum IPv6 packet size.

[Senthil] My question is -- why is it a MUST to fragment the packet and then translate as opposed to translate and fragment.
"If the DF flag is not set and the IPv4 packet will result in an IPv6 packet larger than 1280 bytes the IPv4 packet MUST be fragmented
   prior to translating it."

The above sentence says one *must* fragment prior to translating. Let's take an example. NAT64  receives a IPv4 packet without the DF bit set and the length of the payload (not including IP header) is 1480 bytes. 
NAT64 MUST do this.
- Translate the packet, add the fragment header.
- Send two packets out 
 -- one with 1232 bytes of data + 48 bytes of IPv6 header (40 bytes of ipv6 + 8 bytes of frag hdr).
 -- one with 248 bytes of data + 48 bytes of ipv6 header.

What the text indicates though is
NAT64 must first fragment the packet into two.
1232 byte packet, 248 byte packet.
Then translate and add the fragment header on 1st packet, then do the same on the 2nd packet.

The text bothers me is "prior to translating it". 

> 6. Section 2.1
> Hop Limit: I think the recommendation should be to decrement the TTL 
> and send ICMP TTL exceeded before translation. Translating the packet 
> and decrementing TTL to find out the TTL expired and restoring the 
> packet to its original form seems to be unnecessarily complicating 
> things. We shouldn't even suggest that.
>   

We think this leaves the space for different implementation. The text is from the RFC2765. If the consensus is there, we are fine to make the modification.

[Senthil] I think decrementing the TTL after translation is inefficient. I just noticed that 2765 has the same text too, but that shouldn’t be a reason for us not to do better. 

> Is the SHOULD for dropping the packet and generating the event? I 
> think generating the event should be optional/MAY.
>   

> This document does not address any potential issues that might arise 
> by extracting a IPv4 address from the IPv6 address - particularly 
> addresses like broadcast or loopback addresses etc. I think adding 
> some text around that might be of help.
>   

How about adding:

There are potential issues that might arise by extracting a IPv4 address from the IPv6 address - particularly addresses like broadcast or loopback addresses and the non IPv4-translatable IPv6 addresses, etc. 
Special action SHOULD be taken to avoid security problems.

[Senthil] Sounds good.

Thanks
Senthil

Thanks.

xing

---

From: Xing Li <[email-masked]>
Date: Sat, 19 Dec 2009 10:46:31 +0800

Hi, Senthil,

The version 05 of xlate is uploaded, which reflects your comments in the
previous mail, please check
http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate-05
http://tools.ietf.org/rfcdiff?url2=draft-ietf-behave-v6v4-xlate-05.txt

some comments is inline. I provide some new wordings for the mailing
list. If we reach consensus, I will modify the draft after WGLC.

> "That is needed should the packet pass through an IP/ICMP translator." The packet is already passing through this translator and hence adding a fragment header does not help this device. What I tho…
How about we delete the last sentence. So the wording is

However, when the IPv4 sender does not set the DF bit, the translator
has to ensure that the packet does not exceed the path MTU on the
IPv6 side. This is done by fragmenting the IPv4 packet so that it
fits in 1280 byte IPv6 packets, since that is the minimum IPv6 packet
size. Also, when the IPv4 sender does not set the DF bit the
translator MUST always include an IPv6 fragment header to indicate
that the sender allows fragmentation.

>> Para 1 ".....IPv4 packet MUST be fragmented prior to translating it."

Got the idea. How about we change the wording from MSUT to SHOULD?

If the DF flag is not set and the IPv4 packet will result in an IPv6
packet larger than 1280 bytes the IPv4 packet SHOULD be fragmented
prior to translating it.
>> [Senthil] I think decrementing the TTL after translation is inefficient. I just noticed that 2765 has the same text too, but that shouldn’t be a reason for us not to do better. 
How about

Hop Limit: TTL value copied from IPv4 header. Since the translator
is a router, as part of forwarding the packet it needs to
decrement the IPv4 TTL before the translation.
As part of decrementing the
TTL, the translator (as any router) needs to check for
zero and send the ICMPv4 "ttl exceeded" error.

>> think generating the event should be optional/MAY.
Any comments from the list for changing SHOULD to MAY?

>> Time to Live - Same comment as hoplimit for IPv6.

How about the wording

Time to Live: Hop Limit value copied from IPv6 header. Since the
translator is a router, as part of forwarding the packet it needs
to decrement the IPv6 Hop Limit before the translation.
As part of decrementing the
Hop Limit, the translator (as any router) needs to check for
zero and send the ICMPv6 "hop limit
exceeded" error.

regards,

xing

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 20 Dec 2009 12:18:12 +0100

>>> IPv6 Address with IPv4-translatable IPv6 address and IPv4-converted IPv6

Can someone summerize?

---

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

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: Xu Xiaohu <[email-masked]>
Date: Mon, 21 Dec 2009 09:41:06 +0800

> 发送时间: 2009年12月18日 16:50
> 主题: RE: [BEHAVE] Reason(s) for Modified EUI-64 format to apply to

                             +-------------+
                             | IPv6 only   |
                             | +-----+     |
                             | | H3  |     |
                             | +-----+     |
                             +------+------+
                                    |
                          +---------+---------+
                          |                   |
     +-------------+      | IPv6 Internet     |       +----------------+
     |             +------+                   +-----+-+-----+ IPv4 only|
     | IPv6 only   |      +-------------------+     |NAT64-2|          |
     | +-----+     |                                +-+-----+   +-----+|
     | | H1  |  +-------+  +-------------------+      |         | H2  ||
     | +-----+  |NAT64-1+- +                   +------+         +-----+|
     |    DNS64 +--+----+  | IPv4 Internet     |      +----------------+
     +-------------+       |                   |
                           +-------------------+

In the above scenario, if H3 and H1 send a DNS query for the AAAA record of
H2 respectively, they should obtain different results, e.g., H3 gets an IPv6
address which is synthesized with a NSP used by NAT64-2, while H1 receives
an IPv6 address which is synthesized with a WKP used by NAT64-1. That's to
say, the authoritative DNS server for H2 will return an IPv6 address which
is synthesized with a NSP used by NAT64-2 to a DNS client which is an IPv6
only host without NAT64 (e.g., H3), while returned a null to those DNS
clients which is either an IPv6 only host with NAT64 (e.g., H1) or a
dual-stack host. The latter DNS clients or their DNS64 will send a DNS query
for A record once the resolution for AAAA record fails.).

Is the above statement in accordance with your assumption?  If so, how does
the authoritative DNS server for H2 determine whether the DNS client (e.g.,
H1, H3) is an IPv6 only host w/o NAT64 or an IPv6 only host but with NAT64
(or even dual-stack host)? 

Xiaohu

---

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

---

From: Christian Huitema <[email-masked]>
Date: Mon, 21 Dec 2009 17:55:32 +0000

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

By opposition to administrator who decide to ignore IETF recommendations and do their own thing? I don't think RFC need to cater to those. Do you?

-- Christian Huitema

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 21 Dec 2009 10:25:57 -0800

> Sent: Sunday, December 20, 2009 5:41 PM
> ++---++  +-----+|
> > > > > > the above figure). Besides, the IPv6 only host 
> (e.g. H1) MUST
> > > > > > be able to
> > > > > > synthesize IPv6 address by itself. If either of the 
> above two
> > > > > > conditions is
> > The "IPv6 Internet to IPv4 network" scenario applies to the 
> ISP on the
> right.
> > 
> > Detail:
> > 
> > The ISP on the left is a business, and they made the 
> decision to operate
> an
> > scenario (when the connection is initiated from the IPv6 
> host) and is the
> "the
> > IPv4 Internet to an IPv6 network" (when the connection is 
> initiated from
> the
> > IPv4 side).  Note that a stateful NAT64 will generally not 
> support "the
> IPv4
> > The ISP on the right is another, separate business, and 
> they made the
> decision
> > Internet" (when the connection is initiated from the IPv4 
> side) and is
> "the
> > IPv6 Internet to an IPv4 network" (when the connection is 
> initiated from
> the
> > IPv6 side).
> 
> 
>                              +-------------+
>                              | IPv6 only   |
>                              | +-----+     |
>                              | | H3  |     |
>                              | +-----+     |
>                              +------+------+
>                                     |
>                           +---------+---------+
>                           |                   |
> Is the above statement in accordance with your assumption?  

No.

In all cases, because H2's network is operating a NAT64, its
network will also return AAAA's that cause incoming IPv6
connections to be translated to IPv4 and to be routed to
H2.

Those AAAAs might be static or might be dynamically
created by the DNS64 function operated by H2's network.

-d

> If so, how does

---

From: Xu Xiaohu <[email-masked]>
Date: Wed, 23 Dec 2009 12:36:06 +0800

> 发送时间: 2009年12月22日 2:26

I agree, so the statement made by Marcelo in the previous discussion is not
true. See http://www.ietf.org/mail-archive/web/behave/current/msg07696.html.

Then how about synthesizing the above AAAAs with a specific NSP which starts
with a special binary value (depicted as follows)? That is to say, the
specific NSP is a 96/ prefix which starts with a well-known binary (e.g.,
00010101) while the remaining part is network specific.

This specific NSP is topologically aggregatable, hence it will not result in
routing scalability issues in the IPv6 internet. In addition, since it
begins with a special binary value, the synthetic IPv6 addresses with such a
prefix can be easily distinguished from ordinary IPv6 addresses.

Xiaohu

---

From: Christian Huitema <[email-masked]>
Date: Wed, 23 Dec 2009 07:19:00 +0000

> 00010101) while the remaining part is network specific.

To do that, we would need to define a new class of IPv6 prefixes, with new registry to manage the allocations. That seems like a big operational problem. 

Also, you mention that these new IPv6 prefixes would be topologically aggregatable. That is only true if we allow the prefixes to be used for a variety of address allocations, e.g. both translation and allocation of regular IPv6 addresses. But if we do that, the well known binary prefix will become meaningless.

It seems that you are trying really hard to make sure that addresses constructed by translation can be easily distinguished from regular IPv6 addresses. But why is that such a big issue? At worst, it means that some connection will be a little bit slower than normally expected. This happens all the time in multihoming scenario, without translation.

-- Christian Huitema

---

From: GangChen <[email-masked]>
Date: Wed, 23 Dec 2009 17:24:18 +0800

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

> legitimately obtain a prefix
> legitimately obtain?
> By opposition to administrator who decide to ignore IETF recommendations
> and do their own thing? I don't think RFC need to cater to those. Do you?
>

In other words, that only applies to the NSP.
Thanks for the clarification.

BRs

Gang

---

From: Xu Xiaohu <[email-masked]>
Date: Thu, 24 Dec 2009 11:05:33 +0800

> 发送时间: 2009年12月23日 15:19
> 收件人: Xu Xiaohu; 'Dan Wing'; 'marcelo bagnulo braun'
> 抄送: [email-masked]
> > This specific NSP is topologically aggregatable, hence it will not
result
> > begins with a special binary value, the synthetic IPv6 addresses with
such
> a
> To do that, we would need to define a new class of IPv6 prefixes, with new
> registry to manage the allocations. That seems like a big operational
problem.
> 
> Also, you mention that these new IPv6 prefixes would be topologically
> aggregatable. That is only true if we allow the prefixes to be used for a
variety
> of address allocations, e.g. both translation and allocation of regular
IPv6
> addresses. But if we do that, the well known binary prefix will become
> meaningless.

No, these specific NSPs can be aggregated as 15::/8 to the utmost extent. It
has nothing to do with the aggregation of the regular IPv6 addresses.

> It seems that you are trying really hard to make sure that addresses
constructed
> by translation can be easily distinguished from regular IPv6 addresses.
But
> why is that such a big issue? At worst, it means that some connection will
be
> a little bit slower than normally expected. This happens all the time in
> multihoming scenario, without translation.

Irrelated to whether slower or faster. The major purpose is to avoid ADDRESS
FAMILY translation if possible.

Xiaohu

---

From: Kentaro Ebisawa <[email-masked]>
Date: Thu, 31 Dec 2009 04:08:14 +0900

Hi,

Some comments inline.

On Sat, 19 Dec 2009 10:46:31 +0800

> packet larger than 1280 bytes the IPv4 packet SHOULD be fragmented

I think what we want to make sure is it will be fragmented regardless of
the link MTU of the traslator's IPv6 interface when DF bit was not set.
To fragment it prior to or after the tanslation is an implementation
issue, but there might be more risk of "fragmenting only when it exeeds
link MTU" if one does it after the translation.

So rather than changing it to SHOULD, how about changing it like below ?

   If the DF flag is not set and the IPv4 packet will result in an IPv6
   packet larger than 1280 bytes, the packet MUST be fragmented so the
   resulting IPv6 packet (with Fragment header added to each fragment)
   will be less than or equal to 1280 bytes. For example, if the packet
   is fragmented prior to the translation, the IPv4 packets must be
   fragmented so that their length, excluding the IPv4 header, is at
   most 1232 bytes (1280 minus 40 for the IPv6 header and 8 for the
   Fragment header).  The resulting fragments are then translated
   independently using the logic described below.

> zero and send the ICMPv4 "ttl exceeded" error.

I agree that it will be more efficient to decrement TTL before translation,
but it should not be specified in the RFC but chosen by who implements it.

So I would prefer keeping the original sentence.

For example, one might already have an software module which has full IPv6
router functionality and chose to implement an module doing the translation.
In that case, translator (as a system) will do translation first and then
pass the translated IPv6 packet to the IPv6 router module which will handle
TTL and any other routing/forwarding functionality.

> zero and send the ICMPv6 "hop limit

As previously mentioned, I think this should be up to the implementation
and prefer keeping the original sentence.

Regards,
-- 
Kentaro Ebisawa <[email-masked]>

---

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Wed, 30 Dec 2009 11:43:45 -0800

-----Original Message-----
From: Kentaro Ebisawa [mailto:[email-masked]] 
Sent: Wednesday, December 30, 2009 2:08 PM
To: Xing Li; Senthil Sivakumar (ssenthil)
Cc: [email-masked]
Subject: Re: [BEHAVE] Comments on draft-ietf-behave-v6v4-xlate-04

Hi,

Some comments inline.

[Senthil] That sounds fine, as long as the MUST does not specifiy
whether one should translate and fragment or fragment & translate.

> >> 6. Section 2.1
> >>
> >> [Senthil] I think decrementing the TTL after translation is
inefficient. I just noticed that 2765 has the same text too, but that
shouldn't be a reason for us not to do better. 
> >>
> >>     
> How about
> 
> Hop Limit: TTL value copied from IPv4 header. Since the translator is 
> a router, as part of forwarding the packet it needs to decrement the 
> IPv4 TTL before the translation.
> TTL, the translator (as any router) needs to check for zero and send 
> the ICMPv4 "ttl exceeded" error.

I agree that it will be more efficient to decrement TTL before
translation, but it should not be specified in the RFC but chosen by who
implements it.

For example, one might already have an software module which has full
IPv6 router functionality and chose to implement an module doing the
translation.
In that case, translator (as a system) will do translation first and
then pass the translated IPv6 packet to the IPv6 router module which
will handle TTL and any other routing/forwarding functionality.

[Senthil] I think the original wording is not good. We know the
translator is a router which has both IPv4 and IPv6 functionality built
in -- so why do you have to specify the ttl is to be decremented, as all
the routers do that (IPv4 or IPv6). I am saying if it is not to be done
by translator don't specify it. 

> translator is a router, as part of forwarding the packet it needs to 
> decrement the IPv6 Hop Limit before the translation.
> Hop Limit, the translator (as any router) needs to check for zero and 
> send the ICMPv6 "hop limit exceeded" error.

[Senthil] Same sentiment as above.

Thanks
Senthil

Regards,

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 31 Dec 2009 09:15:25 +1300

On 2009-12-31 08:43, Senthil Sivakumar (ssenthil) wrote:
...
> by translator don't specify it. 

No, we don't *know* that the translator is a router. Actually the document
is inconsistent on this. The clearest statement is:

2.7.  Knowing when to Translate

   If the IP/ICMP translator is implemented in a router providing both
   translation and normal forwarding,...

which makes it clear that the tranlsator may or may not be in the
same box as a router. The above extract from section 2.1 asserts that
the translator is a router. Then section 1.4 says:

   Note that the translator MUST behave as a router, i.e. the
   translator MUST send packet too big error message when the packet
   size exceeds the MTU of the next hop interface.

So, I think we need to clean up all these three to make them
consistent.

For example, IMHO 2.1 should say

   If the translator is combined with an IPv6 router, the router MUST
   perform normal Hop Count processing [RFC2460]. Otherwise the
   translator MUST emulate this processing.

and so one for all three points.

    Brian

---

From: Dave Thaler <[email-masked]>
Date: Wed, 30 Dec 2009 20:18:15 +0000

> Behalf Of Brian E Carpenter
> Sent: Wednesday, December 30, 2009 12:15 PM
> Cc: [email-masked]; Kentaro Ebisawa; Xing Li
> Subject: [BEHAVE] Is a translator a router? [draft-ietf-behave-v6v4-
> xlate-05]
> 

I think the translator must decrement the TTL (either before or
after translation), which makes it a router in my book.

-Dave

---

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Wed, 30 Dec 2009 12:24:14 -0800

We always have the confusion of whether a translator (nat or nat64) a
router, a host or both?
In my opinion it acts as both - even though I heard conflicting
opinions. 
- Why it is a router?
It decrements the TTL and forwards the packet.

- Why is it a host ?
It does reassembly of fragments, segments that are purely non-router
functionality and hence a host.

I agree that the draft is a little inconsistent on the wording. But my
question is when is a translator not a router?

Senthil

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]] 
Sent: Wednesday, December 30, 2009 3:15 PM
To: Senthil Sivakumar (ssenthil)
Cc: Kentaro Ebisawa; Xing Li; [email-masked]
Subject: Is a translator a router? [draft-ietf-behave-v6v4-xlate-05]

> translation, but it should not be specified in the RFC but chosen by 
> who implements it.
> 
> translator is a router which has both IPv4 and IPv6 functionality 
> built in -- so why do you have to specify the ttl is to be 
> decremented, as all the routers do that (IPv4 or IPv6). I am saying if

> it is not to be done by translator don't specify it.

No, we don't *know* that the translator is a router. Actually the
document is inconsistent on this. The clearest statement is:

which makes it clear that the tranlsator may or may not be in the same
box as a router. The above extract from section 2.1 asserts that the
translator is a router. Then section 1.4 says:

So, I think we need to clean up all these three to make them consistent.

    Brian

---

From: Kentaro Ebisawa <[email-masked]>
Date: Thu, 31 Dec 2009 05:50:03 +0900

Hi,

I also think translator act as both, router and host.
My point was we should let implementor decide when to decrement TTL.
(before or after the translation)

To answer to the Brian's comment :

> box as a router. 

One can implement a translator which would NOT forward packet which doesn't
need translation. Such implementation would not do v6 to v6 nor v4 to v4
packet forwarding, but will act as a router for v6v4 or v4v6 packet and do
v6v4(v4v6) packet forwarding.

I think in the sentense above, "translation" implies "translation + v6v4(v4v6) forwarding"
and "normal forwarding" means "v4v4 or v6v6 forwarding without translation".

So for both cases, translator act as a router (decrements TTL).

On Wed, 30 Dec 2009 12:24:14 -0800

---

From: Kentaro Ebisawa <[email-masked]>
Date: Thu, 31 Dec 2009 06:09:51 +0900

Hi,

Comments inline.

On Wed, 30 Dec 2009 11:43:45 -0800

> whether one should translate and fragment or fragment & translate.

[Kentaro] MUST is only for the fragmentation. And does not specify the order.

> by translator don't specify it. 

[Kentaro] Translator acting as router implies it needs to decrement TTL.
So in that point of view, you don't have to specify it in this document.

But in this context, I think we should remind to decrement TTL since it
will be misleading if you delete it and just write :

 >  Hop Limit: TTL value copied from IPv4 header.

If only above is mentioned in the doc, then one might think this is an exception
for translator and just need to copy the value without decrementing it.

So understanding that it might be rephrasing something already implied,
I think we should leave the explanation of decrementing TTL for clarification.

Thanks,

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 31 Dec 2009 14:15:54 +1300

I perhaps wasn't clear enough. I agree that a node that contains
a translator should always decrement the hop count; it's clearly
a hop.

But consider what happens to the packet after it's been translated.
Does the node simply send the packet off to its default router,
like any other IPv6 node? Or does it pass the packet on to
a routing daemon, with its own routing table and executing at
least one routing protocol? If it's the second case, and we
don't specify things more carefully, the hop count will get
decremented twice in one node (once by the translator and
then a second time by the routing daemon). If we don't want that
to happen, we need to specify the two cases separately.

That is what my proposed text does (for the v4 to v6 direction):

       Brian

---

From: Dave Thaler <[email-masked]>
Date: Thu, 31 Dec 2009 05:52:24 +0000

> Sent: Wednesday, December 30, 2009 5:16 PM
> To: Kentaro Ebisawa
> Cc: [email-masked]; Xing Li
> Subject: Re: [BEHAVE] Is a translator a router? [draft-ietf-behave-
> v6v4-xlate-05]
> 
> a routing daemon,

A routing daemon doesn't handle packets (at least in most routers).
The forwarding place in the kernel does.  A routing daemon just
handles routing protocols.

> with its own routing table and executing at
> least one routing protocol? 

A router need not execute at least one routing protocol.
If a router uses static routes, it's still a router.

> If it's the second case, and we

I don't think you need to specify that level of detail.

-Dave

>    translator MUST emulate this processing.

The above text is confusing to me, since "combined" is ambiguous.
If a v4/v6 translator is running on the same box as a regular
IPv6 router, but they're not chained, just running ships in the night,
they're still "combined" in the "same box" sense.

-Dave

> same

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 01 Jan 2010 08:35:44 +1300

> If a router uses static routes, it's still a router.

Yes, OK. I phrased it carelessly.

> they're still "combined" in the "same box" sense.

Sure, "combined in series" is the case that concerns me. Specifically,
I'm concerned if a perfectly OK forwarding engine (which decrements
hop count) is combined in series with a perfectly OK translator (which
decrements hop count).

    Brian

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 31 Dec 2009 16:37:43 -0500

> hop count) is combined in series with a perfectly OK translator (which

Surely this is a scenario that needs to be faced head on?  It's almost
certainly going to happen.  Even just noting, "This can happen.  It
might be bad," would be useful.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Joel Jaeggli <[email-masked]>
Date: Thu, 31 Dec 2009 14:40:11 -0800

Considered in the context of what is done in an ipv4 implementation
(e.g. linux iptables nat), header rewrite is performed (in iptables)
before handing off for forwarding and it's the forwarding stage
(ip_forward.c) that is responsible for decrimenting the ttl before
dropping it in the output queue.

joel

---

From: Dave Thaler <[email-masked]>
Date: Fri, 1 Jan 2010 02:45:27 +0000

> hop count) is combined in series with a perfectly OK translator (which

I guess it doesn't particularly concern me.  It seems to be an internal 
implementation detail.  If someone really chooses to implement a 
single physical box that appears as two separate virtual hops,
one behind the other, it shouldn’t break anything.

-Dave

---

From: Christian Huitema <[email-masked]>
Date: Fri, 1 Jan 2010 03:22:07 +0000

What about acknowledging that a translator is a third type of nodes, besides hosts and routers? A Chimera of sorts, which should be recognized as such in the Internet architecture?

-- Christian Huitema