Subject: [BEHAVE] Modified EUI-64 format

From: Dave Thaler <[email-masked]>
Date: Thu, 2 Jul 2009 04:06:21 +0000

Section 5.2.5 of draft-xli-behave-v4v6-prefix-00 says:
> The selection of the prefix length may affect the EUI-64 format,
> since the subnet may not be in the 64 bit boundary.  However, there
> is no contradiction to [RFC4291], which states that first, an
> interface identifier has to be unique on the LAN-or-whatever it is
> on.  And second, when the interface identifier is a MAC address it
> should be in a format related to a MAC Address - except that it is
> different.  So, especially given privacy addressing, we can't really
> assume that the router or neighboring host is going to extract a MAC
> address from the interface identifier and directly use it to direct a
> datagram to another host; rather, the relationship between a MAC
> address and an interface identifier has a level of indirection
> managed by Neighbor Discovery.

While it's true there's no "contradiction" per se, there is a definite
constraint.  Specifically RFC 4291 section 2.5.1 states:

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

The Modified EUI-64 format reserves the universal/local bit for that
use.   This is then restated in that RFC both in section 2.5.1:

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

as well as in Appendix A, which explains that there are a number
of approaches, but all of them adhere to the universal/local
bit.

Similarly, with privacy addresses referred to in the draft quote
at top, RFC 3041 section 3.2.1 point 3 forces the randomized
interface identifier to adhere to this requirement, so that it's
a 63-bit random number, not a 64-bit random number.  And with
CGAs, RFC 3972 section 4 point 6 similarly forces a generated
interface identifier to adhere to this requirement. (As an aside,
it also reserves the "g" bit which is actually unnecessary
since it's not IEEE EUI-64-derived.  RFC 4291 only discusses
the "g" bit for addresses derived from IEEE EUI-64's, which
is why RFC 3041 and a translation format can still use that bit).

Hence it is not legal for an embedded IPv4 address to span
this bit unless the prefix starts with binary 000.  So either
a well-known prefix can be used that starts with binary 000,
or else any embedded (or obscured) IPv4 address has to end
before the 71st bit (i.e. LIR prefix length <= 38) or start
after it (i.e. LIR prefix length >= 71).

-Dave

---

From: Rémi Després <[email-masked]>
Date: Fri, 3 Jul 2009 15:10:01 +0200

>> constructed in Modified EUI-64 format.

True.
However, this in a section on Interface Identifiers which starts with:
"Interface identifiers in IPv6 unicast addresses are used to identify  
interfaces on a link."
In the case of an embedded IPv4 address translated by an SIIT, the  
last 64 bits are never used "identify an interface on a link".
Rules specified for addresses processed at the link layer need not to  
be extended to addresses that are not.
Especially since RFC 4291 also says:
"Except for the knowledge of the subnet boundary discussed in the  
previous paragraphs, nodes should not make any assumptions about the  
structure of an IPv6 address."
In my understanding, this means that, unless a node is exploiting an  
IID for a link layer function, it should not constrain in any way the  
format of IPv6 addresses beyond prefixes it exploits locally.

> after it (i.e. LIR prefix length >= 71).

If despite the discussion above it is concluded that embedded  
addresses that span IID "u" and "g" bits are "formally" illegal, an  
action should imho be taken to make it formally legal.
Reasons are:
- it is useful to keep SIIT as simple and flexible as it can be
- there is no identified technical or operational harm (if one would  
know one, it would be worth knowing).

Regards,
RD

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

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 03 Jul 2009 17:14:39 +0100

On 2009-07-03 14:10, Rémi Després wrote:
...
> If despite the discussion above it is concluded that embedded addresses
> that span IID "u" and "g" bits are "formally" illegal, an action should
> imho be taken to make it formally legal.
> Reasons are:

The reason that *strict* compatibility with EUI-64 was designed in was
because we wanted to be certain that IPv6 automatic self configuration
would work even if (when) LANs switch to 64 bit hardware addressing.
Obviously, people were thinking about a timescale of several decades.

I think Rémi is correct that this argument could be relaxed for a
SIIT-assigned address, but I'd really want that to be debated in 6man
and queued up for whenever RFC4291bis is published. It shouldn't
be hidden in another document.

    Brian

---

From: Dave Thaler <[email-masked]>
Date: Fri, 3 Jul 2009 17:01:08 +0000

> -----Original Message-----
> From: Rémi Després [mailto:[email-masked]]
> Sent: Friday, July 03, 2009 6:10 AM
> To: Dave Thaler
> Cc: Xing Li; Behave WG
> Subject: Re: [BEHAVE] Modified EUI-64 format
>
>

This is rebutted in the paragraph quoted below about future technology.

> know one, it would be worth knowing).

This would be a change to the IPv6 addressing architecture, and
_cannot_ be done by the Behave WG, only by 6man.  And it would
prevent the possibility mentioned above, which is the "identified"
issue.  It's not at all clear there'd be consensus on this, given
there are groups (like HIP?) which may actually want to use the
bit as suggested.

-Dave

---

From: Dave Thaler <[email-masked]>
Date: Fri, 3 Jul 2009 17:03:43 +0000

> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Friday, July 03, 2009 9:15 AM
> To: Rémi Després
> Cc: Dave Thaler; Behave WG; Xing Li
> addresses

This isn't about compatability with EUI-64 per se.  This is about
the existence of a universal/local bit in all interface identifiers
(that don't start with binary 000) regardless of whether they're EUI-64
or not, for the potential future use quoted in the RFC.

> be hidden in another document.

I agree it is out of scope for Behave, and would have to be discussed
in 6man.  An SIIT-assigned address doesn't have to worry about this
as long as it uses a well-known prefix starting with binary 000,
which SIIT (RFC 2765) does.

-Dave

---

From: Rémi Després <[email-masked]>
Date: Sat, 4 Jul 2009 09:24:47 +0200

> Obviously, people were thinking about a timescale of several decades.

It's worth underlining that permitting IPv6 addresses whose lower  
bits cannot be used as IID on any IPv6 link to have any value of "u"  
and "g" bits remains compatible with this intention.
It should facilitate relaxation of an historical but unnecessary and  
now harmful constraint.
This relaxation becomes desirable because IPv6 addresses are now  
introduced, as for SIIT, whose first bits are used as routable  
prefixes and whose last bits are never used as IID on any IPv6 link.

> SIIT-assigned address,

> but I'd really want that to be debated in 6man

Full agreement.
(For this, copies of this mail to 6man and Intarea chairs.)

Thanks and regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Sat, 4 Jul 2009 11:52:54 +0200

>>>> advantage of interface identifiers with universal scope.

First to be noted: this discussion is only about 64 bit-IIDs on IPv6  
links.
It needs not to interfere with that on IPv6 addresses whose lower  
bits are never used as IIDs on IPv6 links.

Now on this subject, the sentence that IMHO is even more a problem is  
that which precedes the sentence you quoted:
"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."

As we know, the only escape mechanism to define new IID types is <u',  
g> = <1, 1> (where u' stands for u inverted from EUI-64).
The effect of the sentence above is that the only escape mechanism  
can be used ONLY for new _universal-scope_ IIDs.
This ONLY could however be relaxed because, as long as new IID types  
are not defined yet, all node stacks that have u' = 1 in their IIDs  
also have g = 0.
Stacks that may in the future have both u' and g set to 1 in their  
local IID can therefore have a different behavior without  
incompatibility with the installed base.

If a revision an RFC 4291-bis can be envisaged (see www.ietf.org/mail- 
archive/web/behave/current/msg06102.html), the following proposal  
will take the opportunity to open, by precaution, the possibility of  
new IID formats of BOTH universal and local scope.
The two sentences become:
"IPv6 nodes are not required to validate that interface identifiers  
created with modified EUI-64 tokens with the "u" bit set to universal  
and the "g" bit set to 0 are unique.
NOTE: This use of the universal/local and group bit in the Modified  
EUI-64 format identifier allows development of future technology that  
can take advantage of new types of interface identifiers."

I cannot personally identify any operational problem with this  
relaxation.
Besides, one can think of useful proposals based on it, but this  
should be another debate.
The point here is just about formal openness to unspecified future  
extensions (forward compatibility.)

Regards,
RD

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 04 Jul 2009 14:56:42 +0100

On 2009-07-04 10:52, Rémi Després wrote:
> First to be noted: this discussion is only about 64 bit-IIDs on IPv6 links.
> It needs not to interfere with that on IPv6 addresses whose lower bits
> are never used as IIDs on IPv6 links.

If you read the text in RFC 4291 (and its predecessors), it is clearly

>>    advantage of interface identifiers with universal scope.

That isn't restricted to the notion of a link as such; or if you prefer,
it also applies to virtual links, and SIIT synthesizes a virtual link
under its PREFIX.

This matters if any variant of the routing architecture is adopted
which resembles 8+8 and its descendants. IIDs need to be globally
unique then, so tramping on the g bit would be a problem. So in fact,
although the authority is 6man, the debate would need to be wider.

Note, I'm not necessarily disagreeing with you; but this is a very
big architectural decision. To make rapid progress here, we may
prefer to skip over the u and g bits, even though it's a bit ugly.

   Brian

> As we know, the only escape mechanism to define new IID types is <u', g>
> = <1, 1> (where u' stands for u inverted from EUI-64).
> The effect of the sentence above is that the only escape mechanism can
> be used ONLY for new _universal-scope_ IIDs.
> This ONLY could however be relaxed because, as long as new IID types are
> not defined yet, all node stacks that have u' = 1 in their IIDs also
> have g = 0.
> Stacks that may in the future have both u' and g set to 1 in their local
> IID can therefore have a different behavior without incompatibility with
> the installed base.
> 
> If a revision an RFC 4291-bis can be envisaged (see
> www.ietf.org/mail-archive/web/behave/current/msg06102.html), the
> following proposal will take the opportunity to open, by precaution, the
> possibility of new IID formats of BOTH universal and local scope.
> I cannot personally identify any operational problem with this relaxation.
> Besides, one can think of useful proposals based on it, but this should
> be another debate.
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Rémi Després <[email-masked]>
Date: Mon, 6 Jul 2009 09:52:31 +0200

Brian,

Thanks for your comments.
Further remarks below.

Regards,
RD

> intended to be broader than that:

I had not read RFC 3513 yet (the predecessor of RFC 4291 where the  
word "global" was used rather than "universal" in the considered  
sentence), but I agree that both express a constraint on u and g bits  
"in general".
An update of the the document is therefore needed, if this constraint  
has to be relaxed, as I suggest, *for IPv6 addresses that by  
construction will never appear as source or destination on any IPv6  
link*,
This update is IMHO desirable in the context of 2009 as new IPv6- 
address formats are under study, in particular for SIIT.

> although the authority is 6man, the debate would need to be wider.

While I understand that ISATAP introduces an "IPv6 virtual link" (non- 
broadcast multiple access in this case), I don't believe the IPv4  
side of a SIIT can be considered as an "IPv6 virtual link": nothing  
is IPv6 on this side.
Yet I take the point that it should be clear that the u-g bits  
constraint that MUST apply to IPv6 addresses that may be used on an  
IPv6 links concerns  BOTH  physical AND virtual IPv6 links.

My second point applies only to addresses that can appear on IPv6  
links (the first point was about those that can't).
I hope it's clear that change is proposed to the rule that, on IPv6  
links (physical or virtual), addresses MUST have 64-bits IIDs, with u- 
g bits conforming to modified EUI-64 rules.

The point is only that there remains only one combination of u and g  
bits available for new IID formats (namely u=1, g=1), and that  
therefore it should be available for all new IID formats, NOT ONLY  
for new IID formats that have universal scope, but ALSO for those  
that have local scope.

This of course isn't an amendment of EUI-64 itself, just an amendment  
of modified EUI-64 rules.

> big architectural decision.

Not so big in my understanding.
It's no more than this:
Point-1: u and g rules apply ONLY to IPv6 addresses that may be used  
on IPv6 links (real or virtual).
Point-2: in IIDs, the only escape combination of u and g bits MAY be  
used for ALL possible new IID formats (having universal OR local  
scopes).

If there are real technical objections to this, they have to be  
looked at, but I personally don't know any.

> To make rapid progress here, we may

When identified and possible, aren't simple and clean designs always  
preferable to ugly ones, in particular to make future work easier?
(When a significant simplification is seen to be possible now, this  
is IMHO the best time to decide it: later it is likely to be more  
difficult).

>> can
>> local
>> should

---

From: Christian Huitema <[email-masked]>
Date: Mon, 6 Jul 2009 16:26:47 +0000

May I throw a dose of caution in this debate about host identifiers formats?

Many transition mechanisms rely on encoding information in the 64 bit host identifier. This is of course a tempting design point, because it diminishes the amount of state that servers have to keep. For example, Teredo encodes mapped port numbers and IPv4 addresses in the host identifiers, so Teredo servers can be stateless. ISATAP uses a similar mechanism, and a number of proposals follow the same design. But the gain, the reduction of server load, comes at a cost. I am guilty, I did it with Teredo, but I still would like to encourage designers of new protocols to consider the downside of these "structured identifiers" encoding when they consider new approaches.

Structured host identifiers are incompatible with cryptographically generated addresses, as used in SEND and proposed in SHIM6. We can argue that SEND is a local protocol, and that the use of SEND can be decided on a subnet basis. However, cryptographically binding addresses to public keys has huge potential, not just inside subnets. Think about secure mobility, secure re-homing, opportunistic IPSEC, and other kinds of end-to-end security. Standardizing structured identifiers breaks that.

Structured identifiers are not compatible with privacy address extensions. Moreover, embedding addresses in identifiers discloses information that would otherwise have remained hidden behind the NAT and the firewall. The IPv4 address encoded in the host identifier is passed to third parties, stored in server logs. The third parties now have access to the local addresses used inside the corporation. They can analyze subnet structure. At a minimum, this should be a privacy concern.

Combining embedded addresses with stateless servers opens the door to various kind of denial of service attacks. We analyzed several such attacks in the security analysis of Teredo, but the attacks are not specific to Teredo. The attacks derive from the stateless nature of the transition mechanism. A transition router, relay or gateway will receive a packet, extract the IPv4 next hop from the structured identifier, and blindly relay the packet towards that next hop, whether that next hop participates in the transition scheme or not. Based on that, attackers can build denial of service attacks, can hide their tracks in reflection attacks, can spoof addresses.

The alternative is obviously to leave the identifier unstructured, and to require transition servers to maintain the required mapping state. For example, if I had to redesign Teredo today, I would require servers to maintain tables of mapping between the Teredo hosts that they serve and the corresponding mapped addresses. This would increase the cost of servers somewhat, but it would improve security and privacy aspects of the protocol. The same could easily be done for ISATAP, letting routers use a variation of non-multicast neighbor discovery to enable traffic.

I would like to encourage designers of new transition schemes to study that alternative. Leave the host identifier unstructured, or maybe use SEND as a structure. Keep the transition state in a transition server. Use caching to increase reliability and diminish server load.

-- Christian Huitema

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 06 Jul 2009 21:26:27 +0200

Christian Huitema escribió:
> Many transition mechanisms rely on encoding information in the 64 bit host identifier. This is of course a tempting design point, because it diminishes the amount of state that servers have to keep.
Actually, i think it is not only the reduced state in the translation 
device, but also the need for coordination between different services.
To put it more concretely, consider the case of the DNS64 and NAT64
(FWIW, DNS64 is a service that translates A RR into AAAA RR and the 
NAT64 is the device that translates the IP packets.

for these two to work together, the IPv6 address contained in the 
synthetic AAAA RR representing the IPv4 address, must be then treated by 
the NAT64 device and the IPv4 address is extracted.

The interesting property is that the only thing that needs to be 
synchronized between the DNS64 and the NAT64 is the prefix used to 
represent IPv4 addresses in IPv6 address space.

If we give up embedding the IPv4 address in the IPv6 representation, 
then we need to exhcnage the binding state of the IPv4 and its IPv6 
representation between the dns64 and the nat64, and i think this would 
add significant complexity and reduce the robustness of the overall solution

>  For example, Teredo encodes mapped port numbers and IPv4 addresses in the host identifiers, so Teredo servers can be stateless. ISATAP uses a similar mechanism, and a number of proposals follow the same design. But the gain, the reduction of server load, comes at a cost. I am guilty, I did it with Teredo, but I still would like to encourage designers of new protocols to consider the downside of these "structured identifiers" encoding when they consider new approaches.
>
Maybe this can be addressed by having the Pref64 i.e. the prefix used to 
make representations of IPv4 addresses in the IPv4 address space to be 
shorter than 32 bits.
This would allow to have the Pref64+ IPv4 address shorter than 64 bits 
and we can still embed crypto info in the last 64 bits as done with CGAs

> Structured identifiers are not compatible with privacy address extensions. Moreover, embedding addresses in identifiers discloses information that would otherwise have remained hidden behind the NA…
The concerns about privacy can be mitigated by using algorithms that 
scramble the bits of the IPv4 address around.

> Combining embedded addresses with stateless servers opens the door to various kind of denial of service attacks. We analyzed several such attacks in the security analysis of Teredo, but the attacks…
but the deployment model for these transition tools seem to be different 
than teredo, since they are expected to be locally managed, and not a 
public server like 6to4 or teredo, so the translators are expected to 
rely packets from their clients.

Regards, marcelo

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 7 Jul 2009 09:26:39 +0200

> It should facilitate relaxation of an historical but unnecessary and  

It's not harmful.

Breaking a practice that has been in place for more than a decade that  
COULD be beneficial in the future for no good reason is a bad idea.

Leave the u/l and g bits alone.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 7 Jul 2009 09:36:09 +0200

On 6 jul 2009, at 21:26, marcelo bagnulo braun wrote:

> Maybe this can be addressed by having the Pref64 i.e. the prefix  
> used to make representations of IPv4 addresses in the IPv4 address  
> space to be shorter than 32 bits.
> This would allow to have the Pref64+ IPv4 address shorter than 64  
> bits and we can still embed crypto info in the last 64 bits as done  
> with CGAs

Why would the NAT64 need CGA IIDs in the bottom 64 bits of IPv6  
addresses that represent IPv4 addresses?

CGAs are only useful when they're assigned to a host, not in the  
address space of protocol A that represents the address space of  
protocol B.

> scramble the bits of the IPv4 address around.

Sorry, but the idea that privacy should apply to NAT64 is stupid.

If you want privacy, set up an IPsec tunnel to the NAT64. Or get an  
ISP that you trust enough to let them see the destination addresses in  
your packets.

---

From: Rémi Després <[email-masked]>
Date: Tue, 7 Jul 2009 12:03:17 +0200

Christian,

Thanks for this analysis.
Caution is indeed a must before any amendment of a basic document.

As my proposal is, its relationship with cryptographically generated  
addresses (and with secure neighbor discovery which uses it) should  
however not be a problem.

The proposal is, in short:

- Since CGAs are to be used on IPv6 links, they are not concerned  
with Point-1.

- Besides, CGAs are compatible with the u and g bits rule (per RFC  
3972 where step 6 is "Form an interface identifier from Hash1 by  
writing the value of  Sec into the three leftmost bits and by setting  
bits 6 and 7 (i.e., the "u" and "g" bits) to zero."
They are therefore not concerned with point-2.

It is true that secure neighbor discovery of the RFC-3971 SEND  
protocol cannot apply to any new IID format that has the escape value  
1-1 of u-g bits.
But NEW IIDs that cannot be subject to SEND may be useful too (like  
existing and largely deployed IIDs that are based on MAC addresses  
are useful despite their impossible use in SEND).
Point-2 is only to avoid that new IID formats using the escape  
combination would be a priori restricted to IIDs having universal scope.

So, be cautious, yes, but if analysis shows that some restrictions  
lack technical justification, and may render some progress more  
complex or impossible, don't be timorous and relax them.

Regards,

RD

> Many transition mechanisms rely on encoding information in the 64  
> bit host identifier. This is of course a tempting design point,  
> because it diminishes the amount of state that servers have to  
> keep. For example, Teredo encodes mapped port numbers and IPv4  
> addresses in the host identifiers, so Teredo servers can be  
> stateless. ISATAP uses a similar mechanism, and a number of  
> proposals follow the same design. But the gain, the reduction of  
> server load, comes at a cost. I am guilty, I did it with Teredo,  
> but I still would like to encourage designers of new protocols to  
> consider the downside of these "structured identifiers" encoding  
> when they consider new approaches.
>
> Structured host identifiers are incompatible with cryptographically  
> generated addresses, as used in SEND and proposed in SHIM6. We can  
> argue that SEND is a local protocol, and that the use of SEND can  
> be decided on a subnet basis. However, cryptographically binding  
> addresses to public keys has huge potential, not just inside  
> subnets. Think about secure mobility, secure re-homing,  
> opportunistic IPSEC, and other kinds of end-to-end security.  
> Standardizing structured identifiers breaks that.
>
> Structured identifiers are not compatible with privacy address  
> extensions. Moreover, embedding addresses in identifiers discloses  
> information that would otherwise have remained hidden behind the  
> NAT and the firewall. The IPv4 address encoded in the host  
> identifier is passed to third parties, stored in server logs. The  
> third parties now have access to the local addresses used inside  
> the corporation. They can analyze subnet structure. At a minimum,  
> this should be a privacy concern.
>
> Combining embedded addresses with stateless servers opens the door  
> to various kind of denial of service attacks. We analyzed several  
> such attacks in the security analysis of Teredo, but the attacks  
> are not specific to Teredo. The attacks derive from the stateless  
> nature of the transition mechanism. A transition router, relay or  
> gateway will receive a packet, extract the IPv4 next hop from the  
> structured identifier, and blindly relay the packet towards that  
> next hop, whether that next hop participates in the transition  
> scheme or not. Based on that, attackers can build denial of service  
> attacks, can hide their tracks in reflection attacks, can spoof  
> addresses.
>
> The alternative is obviously to leave the identifier unstructured,  
> and to require transition servers to maintain the required mapping  
> state. For example, if I had to redesign Teredo today, I would  
> require servers to maintain tables of mapping between the Teredo  
> hosts that they serve and the corresponding mapped addresses. This  
> would increase the cost of servers somewhat, but it would improve  
> security and privacy aspects of the protocol. The same could easily  
> be done for ISATAP, letting routers use a variation of non- 
> multicast neighbor discovery to enable traffic.
>
> I would like to encourage designers of new transition schemes to  
> study that alternative. Leave the host identifier unstructured, or  
> maybe use SEND as a structure. Keep the transition state in a  
> transition server. Use caching to increase reliability and diminish  
> server load.
>
> -- Christian Huitema
>
>
>

---

From: Rémi Després <[email-masked]>
Date: Tue, 7 Jul 2009 12:22:25 +0200

Le 7 juil. 09 à 09:26, Iljitsch van Beijnum a écrit :

>> bits cannot be used as IID on any IPv6 link to have any value of  
>> "u" and "g" bits remains compatible with this intention.
>> It should facilitate relaxation of an historical but unnecessary  
>> and now harmful constraint.
>
> It's not harmful.

It is restrictions on formats of IPv6 addresses that identify IPv4- 
only hosts which is harmful.
As Brian puts it "To make rapid progress here, we may prefer to skip  
over the u and g bits, even though it's a bit ugly."
Ugliness in design is indeed harmful.

Some other cases are IMHO likely to appear, but SIIT is in my  
understanding enough for a conclusion now to be desirable.

> Breaking a practice that has been in place for more than a decade  
> that COULD be beneficial in the future for no good reason is a bad  
> idea.

It has been more an artificial restriction without practical  
consequence so far, than a "practice".
Relaxing for the future the two unnecessary constraints I described  
will have no consequence on existing products and on how they operate.

Regards,
RD

---

From: Christian Huitema <[email-masked]>
Date: Tue, 7 Jul 2009 13:40:40 +0000

CGA are not only used in SEND, but also in SHIM6, and they have a clear potential in other applications. You can take the narrow view that CGA are only useful to secure neighbor discovery, but doing that limits any future application.

Iljitsch makes another point, that CGA are inherently not useful in a NAT context, because the host identifier is assigned by the NAT, and mostly unknown to the host. Clearly, this is a valid argument. However, if you consider NAT64 close to the legacy IPv4 server, the picture becomes different. The NAT64 acts then as an extension of the IPv4 server, and may be tasked to prove that "you are really speaking to this host".

I think Iljitsch missed the point about privacy. Consider an IPv4 enterprise network manager that wants to gain IPv6 access. Embedding the internal IPv4 addresses in the IPv6 address makes these addresses public, while previously they were private. In a stateless scheme, they also become reachable.

-- Christian Huitema

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 7 Jul 2009 17:32:27 +0200

> only hosts which is harmful.

No, because there is no valid reason to want the IPv4 address to sit  
in this particular place of the IPv6 address. There is plenty of room  
to the right, and with a well known prefix, also enough room to the  
left.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 7 Jul 2009 17:36:27 +0200

On 7 jul 2009, at 15:40, Christian Huitema wrote:

> I think Iljitsch missed the point about privacy. Consider an IPv4  
> enterprise network manager that wants to gain IPv6 access. Embedding  
> the internal IPv4 addresses in the IPv6 address makes these  
> addresses public, while previously they were private. In a stateless  
> scheme, they also become reachable.

I'm not seeing this.

vXuser ----- routers ------ vXserver

v6user -----  NAT64 ------ v4server

In the first case, the addresses are visible everywhere. In the second  
case, the destination address (in one form or another) is visible  
everywhere. How is this suddenly a privacy issue?

---

From: Rémi Després <[email-masked]>
Date: Tue, 7 Jul 2009 17:29:35 +0200

Le 7 juil. 09 à 15:40, Christian Huitema a écrit :

> CGA are not only used in SEND, but also in SHIM6, and they have a  
> clear potential in other applications.

I agree that other useful uses of CGAs are possible.
For those where CGAs never appear in link-layer addresses, compliance  
with the u-g constraint would not be necessary, but having this  
constraint in the CGA spec doesn't hurt.

Neither change to CGAs, nor any restrictions on where they could be  
used in the future, are suggested.

> You can take the narrow view that CGA are only useful to secure  
> neighbor discovery, but doing that limits any future application.

I haven't taken this view... and don't plan to take it!

> Iljitsch makes another point, that CGA are inherently not useful in  
> a NAT context, because the host identifier is assigned by the NAT,  
> and mostly unknown to the host. Clearly, this is a valid argument.  
> However, if you consider NAT64 close to the legacy IPv4 server, the  
> picture becomes different. The NAT64 acts then as an extension of  
> the IPv4 server, and may be tasked to prove that "you are really  
> speaking to this host".
>
> enterprise network manager that wants to gain IPv6 access.  
> Embedding the internal IPv4 addresses in the IPv6 address makes  
> these addresses public, while previously they were private. In a  
> stateless scheme, they also become reachable.
>
>
> -- Christian Huitema
>
>

---

From: Christian Huitema <[email-masked]>
Date: Tue, 7 Jul 2009 18:27:20 +0000

> everywhere. How is this suddenly a privacy issue?

Compare

        V4user ---- NAT44 ---- v4server
And
      V4user ---- NAT64 ---- v6server

If you embed the internal V4 address in the translated address, the v6 servers will see it, while the v4 servers don't.

-- Christian Huitema

---

From: Dave Thaler <[email-masked]>
Date: Tue, 7 Jul 2009 18:37:53 +0000

> From: Iljitsch van Beijnum [mailto:[email-masked]]
> Sent: Tuesday, July 07, 2009 8:32 AM
> To: Rémi Després
> Cc: Brian E Carpenter; Brian Haberman; Behave WG; Dave Thaler; Jari
> Arkko; Ralph Droms; Xing Li; Bob Hinden

I agree with Brian that the Behave WG should leave the u/l bit alone
unless 6man decides to change the address architecture, which is a BIG
decision.  I am not confident of that happening any time soon,
whereas Behave needs to progress rapidly.

I am somewhat sympathetic to Iljitsch's argument above too.

-Dave

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 7 Jul 2009 21:24:23 +0200

> If you embed the internal V4 address in the translated address, the  
> v6 servers will see it, while the v4 servers don't.

We must be talking about different things. What's the internal  
translated address?

If NAT64 is deployed by ISPs then internal addresses are never seen by  
NAT64 translators. The embedded v4 address only appears as a  
destination address from the perspective of the IPv6 host, and even  
with NAT44 the destination address is always sent as-is.

---

From: Dave Thaler <[email-masked]>
Date: Tue, 7 Jul 2009 19:42:51 +0000

Christian Huitema wrote:
[...]
> information that would otherwise have remained hidden behind the NAT
> and the firewall. The IPv4 address encoded in the host identifier is
> passed to third parties, stored in server logs. The third parties now
> have access to the local addresses used inside the corporation. They
> can analyze subnet structure. At a minimum, this should be a privacy
> concern.
[...]

Agree, this is captured in the recently posted
draft-thaler-behave-translator-addressing-00.txt
section 3.1 point 6:

  When the IPv4 network is a private network for which the topology
  is considered sensitive information, the algorithm SHOULD provide
  a way to hide the details of the internal IPv4 subnetting scheme.
  Note that there may be other mechanisms of discovering the
  topology beyond merely inspecting addresses, so while this is not
  sufficient in itself, it is a necessary component of any larger
  solution.  Also note that providing this capability conflicts
  with requirement 3.

Aside: I just discovered the end is a typo (it shouldn't be "3"), it's
referring to the use of dotted-decimal in the textual representation
of IPv6 addresses with embedded IPv4 addresses, which makes
management and troubleshooting easier (which is also listed as
a SHOULD and hence the note that you can't meet both SHOULDs).

-Dave

---

From: Dave Thaler <[email-masked]>
Date: Tue, 7 Jul 2009 19:56:34 +0000

> Sent: Tuesday, July 07, 2009 3:03 AM
> To: Christian Huitema
> Cc: Brian E Carpenter; Xing Li; 6man; Behave WG; Dave Thaler
> Subject: Re: Perils of structured host identifiers (was: Modified EUI-
> 64 format)
>
> Christian,
>

Disagree on multiple accounts.

First, as I stated in other threads the "g" rule doesn't apply to
IPv6 addresses.  It only applies to IEEE EUI-64's (not Modified EUI-64's
or interface identifiers).

Second, it's not true that they only apply to addresses used on IPv6 links.
The u/l bit is reserved for global use as Brian Carpenter also noted.

> used for ALL possible new IID formats (having universal OR local

I can't parse the above sentence.

> - Since CGAs are to be used on IPv6 links, they are not concerned

Disagree, see above.

---

From: Dave Thaler <[email-masked]>
Date: Tue, 7 Jul 2009 20:21:53 +0000

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Iljitsch van Beijnum
> Sent: Tuesday, July 07, 2009 12:36 AM
> To: marcelo bagnulo braun
> Cc: Christian Huitema; 6man; Dave Thaler; Xing Li; Behave WG
> Subject: Re: [BEHAVE] Perils of structured host identifiers
>

Disagree.  I'm not sure it's a big deal, but I disagree it has
0 worth.  CGAs are useful to prevent spoofing.  If a translator
chooses to use a CGA to represent an IPv4 host, then spoofing
it is _extremely_ difficult.

I say I don't consider it a big deal myself because the IPv4 address
was already spoofable within the IPv4 network.

> Sorry, but the idea that privacy should apply to NAT64 is stupid.

Disagree.  People already (whether we like it or not) associate
a certain degree of privacy with NATs.  I also notice you didn't
provide any technical rationale for privacy not applying to
NAT64.  Here we're talking about privacy of details of the IPv4 topology
on the IPv6 side of the NAT64.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 7 Jul 2009 22:40:32 +0200

> it is _extremely_ difficult.

A CGA ties a public key to an address. This is useful if you have  
people sending you packets with a source address that may or may not  
belong to them. In the NAT64 case that would mean that a fake NAT64  
tries to spoof the source addresses (that encode IPv4 addresses) of  
the real NAT64. But since the IPv6 host sets up the session in the  
first place, all of this is taken care of (for a low level of  
security) by return routability. Sessions can also be protected by SSL  
through the NAT64 directly to the IPv4 destination or with IPsec  
between the host and the NAT64. Both of these are much more useful  
than CGA if a high level of security is required. But I don't see how  
it would be, at some point you have to assume that if you give people  
packets they will take care of them.

> a certain degree of privacy with NATs.

In this regard, a NAT64 is no different from a NAT44 in principle.

Of course the fact that a NAT64 will most likely be deployed in the  
ISP network renders the issue largely moot.

What you would have to do is _encrypt_ the destination address to hide  
it from prying eyes. Guess what, we have a protocol for that: IPsec  
tunnel mode. Encrypts the rest of the packet, too.

I would worry more about the DNS, though. Not only is it easily  
spoofable, it also leaks not only addresses but FQDNs. So at the very  
least you'd want DNSSEC and probably also talk to the DNS over IPsec.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 08 Jul 2009 09:42:57 +0200

> packets they will take care of them.

for example, suppose you want to run shim6 on the nat64 box, how would 
you do it if you cannot use the lower 64 bits to store crypto info?

(what i mean is that the IPv6 host talks shim6 with its peer, which in 
this case i behind the nat64 box, so the shim6 protocol runs between the 
IPv6 node and the nat64)

Regards, marcelo

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 8 Jul 2009 11:27:52 +0200

On 8 jul 2009, at 9:42, marcelo bagnulo braun wrote:

> for example, suppose you want to run shim6 on the nat64 box, how  
> would you do it if you cannot use the lower 64 bits to store crypto  
> info?

So then you would have one NAT64 with two Prefix64s, where the CGA  
proves that Prefix64a and Prefix64b belong to the same box? I guess  
you could do that. But the assumption with Shim6 is that you have two  
ISPs that give you two address ranges. That would only apply if the  
NAT64 user and the NAT64 are in different networks, and at least the  
NAT64 is multihomed. So:

                    ISP2
                  /      \
v6client --- ISP1         NAT64
                  \      /
                    ISP3

In my opinion, that would be an extremely unusual case: in networks  
large enough to have some IPv4 addresss space, the NAT64 would be done  
locally. In smaller networks, the ISP would probably do it. Getting  
NAT64 service from a random place somewhere is not impossible, but not  
exactly an obvious solution. Especially because the NAT64 service  
provider would need a mechanism to authenticate its users.

We can go out of our way to find strange use cases and build in  
support for them, but wasn't the idea that we need to get NAT64 in the  
grubby hands of actual users within a reasonable timeframe?

---

From: Rémi Després <[email-masked]>
Date: Wed, 8 Jul 2009 12:16:37 +0200

> whereas Behave needs to progress rapidly.

Real arguments why it is such a BIG decision are IMHO still missing.
If a consensus in the direction you advocate would nevertheless  
prevail, I would hope that, at least, the technical discussion on  
relaxing the two artificial restrictions on u and g bits would not be  
deferred.

> I am somewhat sympathetic to Iljitsch's argument above too.

I agree with part of the argument: there is indeed plenty of room to  
the right of a provider dependent prefix to place an IPv4 address  
without overlapping u and g bits.

But I don't agree with the other part which says that there is "no  
valid reason" to place the IPv4 address next to a PI prefix.
The valid reason I see, and which I find non negligible, is to keep  
the classic hierarchical address architecture.
(With it, address fields to be processed in each independent routing  
zone, are RIGHT AFTER the prefix(es) used to reach the zone).
This address architecture, besides being simple and logical, is more  
open to future extensions: it avoids using all address bits where it  
is not necessary.

Regards,
RD

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 08 Jul 2009 12:02:37 +0200

> provider would need a mechanism to authenticate its users.
I agree this case at this point seems far away, but i am not sure i 
understand the timeframe where nat64 will be around and how pervasive 
they will be.
I was just pointing a case with currently defined technologies that this 
would impose a limitation. the goal was just to put an example that it 
is possible to find

OTOH, as i said earlier, this can be addressed by using a Pref64 shorter 
than 32 bits, so we can embed the IPv4 addres in the prefix part.

Regards, marcelo

---

From: Rémi Després <[email-masked]>
Date: Wed, 8 Jul 2009 15:12:45 +0200

> The u/l bit is reserved for global use as Brian Carpenter also noted.

Well, it gets complex.
Discussing the point offline in Stockholm might be better than by mail.

> I can't parse the above sentence.

As mentioned in a previous mail, the point started from this sentence  
of RFC 4291: "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."

I am not sure myself I sparse this sentence as intended by authors;
It seems to restrict development of future technology that will be  
concerned with the u bit to a technology where IIDs must have  
universal scope.
If it should not be interpreted this way, that's good.

What is important here IMHO is only that u=1 and g=1, the only  
combination that remains available, can be used to "develop new  
technology" without an a priori limitation to universal scope IIDs.

>> - Since CGAs are to be used on IPv6 links, they are not concerned

The point was ambiguous, I have to agree.
Christian apparently also interpreted it as meaning that CGAs must be  
used on IPv6 links. Sorry for this.

An hopefully  better way to express the point could be:
"Since at least some CGAs have be used on IPv6 links, their format,  
being defined in RFC 3972 for all uses, is subject to
  u and g rules. Point-1 consequently doesn't concern CGAs: its  
purpose is to permit u and g rules to be ignored in formats defined  
for addresses that cannot appear on an IPv6 links."

IPv6 addresses of an IPv4-only hosts that are accessed via SIIT are,  
unlike CGAs, concerned with Point-1.
I understand however that a majority may prefer to ignore this fact,  
and submit also these addresses to u and g rules. (IMHO unfortunate,  
but of course possible.)

Regards,
RD

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 08 Jul 2009 16:46:28 +0100

> Real arguments why it is such a BIG decision are IMHO still missing.

Firstly, a parable. In July 2009, an electric pump controlling the water
level in an English canal broke, and there was no spare available.
To avoid catastrophe, the steam powered pumps installed in 1812 and 1843
were restarted. They worked fine until the electric pump was fixed.
Moral: designing technology that will work after 197 years is not such
a bad idea.
http://news.bbc.co.uk/1/hi/england/wiltshire/8134285.stm

I think the IEEE took this view while designing EUI format, and
the IETF did so by adopting modified EUI format. That's why I'm
very cautious about this.

> If a consensus in the direction you advocate would nevertheless prevail,
> I would hope that, at least, the technical discussion on relaxing the
> two artificial restrictions on u and g bits would not be deferred.

A draft aimed at the 6MAN WG would start the discussion.

   Brian

> I agree with part of the argument: there is indeed plenty of room to the
> right of a provider dependent prefix to place an IPv4 address without
> overlapping u and g bits.
> 
> But I don't agree with the other part which says that there is "no valid
> reason" to place the IPv4 address next to a PI prefix.
> The valid reason I see, and which I find non negligible, is to keep the
> classic hierarchical address architecture.
> open to future extensions: it avoids using all address bits where it is
> not necessary.
> 
> Regards,
> RD
> 
> 
>

---

From: Bob Hinden <[email-masked]>
Date: Tue, 7 Jul 2009 17:57:17 -0700

> whereas Behave needs to progress rapidly.

+1

Bob

---

From: Rémi Després <[email-masked]>
Date: Thu, 9 Jul 2009 08:36:01 +0200

> http://news.bbc.co.uk/1/hi/england/wiltshire/8134285.stm

I hope not to be suspected to argue against this ;-).

> very cautious about this.

Being cautious, and designing for many years, whether the IETF u-g  
rule that was derived from EUI-64 can advantageously be partially  
relaxed is part of the technical discussion to be pursued.

>> prevail,

Too late for IETF 75, but yes it can be done for IETF 76 (better late  
than never).

Regards,
RD

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 9 Jul 2009 10:32:02 +0200

> Discussing the point offline in Stockholm might be better than by  

Would that be useful?

The whole point of NAT64 is to work with unmodified clients. So the  
clients don't care.

The DNS64 has to stuff the IPv4 bits somewhere in the IPv6 bits.  
Although it's simpler to do that at a 32 bit boundary (and a 16 bit  
boundary has checksumming advantages), as far as I know all of this  
happens in software and can be handled fast enough even if the rules  
get more complex to have decent performance on a normal DNS server  
like machine.

On the NAT64 translator side I'm a bit worried that vendors may want  
to use hardware acceleration which won't be very flexible with regard  
to the place in the IPv6 address where the IPv4 address appears. For  
that reason, I would like to mandate that the IPv4 bits ALWAYS appear  
in the bottom 32 bits of the IPv6 address. But we can leave this upto  
the vendors, if they can afford to be flexible they'll be flexible and  
customers that need flexibility will buy those products, if  
flexibility is too expensive they won't put it in and only people who  
don't care buy the products.

Especially if we assume that the vendors of DNS64s and NAT64s are  
going to be the same there are no problems with updating the prefix  
format so there is no need to specify one other than a reasonable  
default, which would obviously be <whatever>/96 + IPv4 because that's  
what existing NAT-PTs do.

---

From: Christian Huitema <[email-masked]>
Date: Thu, 9 Jul 2009 14:05:32 +0000

> get more complex to have decent performance on a normal DNS server

The DNS64 does not have "to stuff the IPv4 bits somewhere in the IPv6 bits." It could also use mapping tables to map the IPv4 bits to arbitrary IPv6 bits.

The mapping solution requires that the mapping tables be available to both NAT64 and DNS64, which is an engineering constraint. But it has two big advantages regarding privacy and security. DNS64 and NAT64 do not expose the IPv4 bits, which is a privacy bonus. NAT64 will not perform a reverse mapping unless there is an entry in the table, which is a security bonus.

-- Christian Huitema

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 9 Jul 2009 16:15:25 +0200

On 9 jul 2009, at 16:05, Christian Huitema wrote:

> The DNS64 does not have "to stuff the IPv4 bits somewhere in the  
> IPv6 bits." It could also use mapping tables to map the IPv4 bits to  
> arbitrary IPv6 bits.

There are about 3.7 billion usable IPv4 addresses. Do you really want  
to make a table that big, when the IPv6 host is going to expose  
everything to every IPv6 node it talks to anyway?

---

From: Christian Huitema <[email-masked]>
Date: Thu, 9 Jul 2009 19:55:36 +0000

> everything to every IPv6 node it talks to anyway?

Very few hosts speak to 3.7 billion peers at the same time. Those who do probably have dual stack. In most cases, the working set is much smaller. After all, the existing Nat44 keep state, and they do not explode.

-- Christian Huitema

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 9 Jul 2009 22:34:17 +0200

> Very few hosts speak to 3.7 billion peers at the same time. Those  
> who do probably have dual stack. In most cases, the working set is  
> much smaller. After all, the existing Nat44 keep state, and they do  
> not explode.

Yes, but a NAT44 doesn't have to sync translation mappings with a NAT44.

I don't think IETF standardization for something like this is useful,  
certainly not at this time.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 10 Jul 2009 09:26:43 +1000

In message <[email-masked]>, Iljitsch van Beijn
um writes:
> On 8 jul 2009, at 15:12, R=E9mi Despr=E9s wrote:
> 

	Why make that assumption?  Leave the DNS to those that know
	the DNS.  I don't see a DNSSEC being added a 50USD CPE
	device anytime soon.  I do see NAT64 being added and a basic
	DNS64 being added.

	It took me 1/2 a day to add IPv6 synthesis from IPv4 to a
	DNS server.  It take months to add working DNSSEC to a DNS
	server.

	Stop trying to be over clever here.  KISS.

	Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 10 Jul 2009 10:11:28 +0200

On 10 jul 2009, at 1:26, Mark Andrews wrote:

>> going to be the same

> 	Why make that assumption?

Same reason we make any assumption: to make things simpler.

>  Leave the DNS to those that know
> 	the DNS.

Fine by me, but does that mean you want to create a spec for  
synchronizing arbitrary IPv4-IPv6 mappings between a DNS64 and a NAT64  
(like Christian suggested) so each can be built and sold independently

>  I don't see a DNSSEC being added a 50USD CPE
> 	device anytime soon.  I do see NAT64 being added

There's no point in that, because if those boxes have a public IPv4  
address they can just as easily do NAT44, the point of NAT64 is that  
subscribers don't have their own public IPv4 address.

> 	DNS server.

Yes, if the mapping is simple.

---

From: Rémi Després <[email-masked]>
Date: Mon, 13 Jul 2009 12:15:19 +0200

> Too late for IETF 75, but yes it can be done for IETF 76 (better  
> late than never).

Here is a better way ;-): I just posted draft-despres-sam-03. It  
introduces the subject in its sec. 2.5 and in a note in sec. 3.2.2..  
(The subject happens to be, no surprise, particularly relevant to SAM!)

Regards,
RD

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 13 Jul 2009 15:33:35 +0200

On 13 jul 2009, at 12:15, Rémi Després wrote:

> I just posted draft-despres-sam-03

Can you explain what this does, this wasn't clear after the first 6  
pages of the draft.

---

From: Rémi Després <[email-masked]>
Date: Mon, 13 Jul 2009 16:52:37 +0200

> Can you explain what this does, this wasn't clear after the first 6  

I will present it in the Intarea session.

Its only relationship with Behave, not intended to be discussed now,  
is that its addresses, like those used for NAT64, have no reason to  
be constrained by the format of IIDs.

RD

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 13 Jul 2009 17:04:13 +0200

> I will present it in the Intarea session.

Why would I go to interea and spend precious face-to-face time to hear  
about a draft that I don't even know what it's about?

Ideally, the name should make this clear. If not, the abstract. You  
don't even say what the thing does in the introduction. It's like  
explaining how you have this great method of transportation but not  
telling us whether it rides, sails or flies.

---

From: Dave Thaler <[email-masked]>
Date: Fri, 17 Jul 2009 18:29:37 +0000

Just back from vacation and trying to catch up on threads...

> Sent: Tuesday, July 07, 2009 1:41 PM
> To: Dave Thaler
> Cc: Christian Huitema; Xing Li; 6man; Behave WG
> belong to them.

Right

> In the NAT64 case that would mean that a fake NAT64
> the real NAT64.

Now you lost me.  If a NAT64 (whether stateless or stateful) uses
a CGA, then it can be validated as being the legitimate source of
an IPv6 packet (that was translated from IPv4).  Another IPv6
source cannot spoof such traffic.  Again, I'm not sure this is
a big deal since such traffic can still be spoofed on the IPv4
side, but preventing spoofing within one portion of the network
doesn't have 0 worth.

> But since the IPv6 host sets up the session in the
> security) by return routability.

A low level of security means it's still susceptible to on-path
attacks, whereas CGAs are a much stronger defense.  Also
for stateless (for which is still possible in theory, if not in
practice, to use a CGA if you can get a short enough prefix like
a /32), the session may not be initiated by an IPv6 host.

> Sessions can also be protected by SSL

Right. BTW, that's how Windows 7 works (DNSSEC over IPsec).

-Dave

---

From: Xing Li <[email-masked]>
Date: Sat, 18 Jul 2009 22:01:50 +0800

> after it (i.e. LIR prefix length >= 71).
Thanks for the comments.

(1) For the stateless translator and LIR prefix, it is possible to 
follow the above rule, since there is plenty of room in the IPv6 
address. We will update the stateless address mapping algorithm to meet 
this requirement.
(2) With our present simple v6v4 translation solution, this rule may not 
be necessary. However, we will participate in the 6man's debate and 
follow the 6man's decision.
(3) We believe it is also possible to implement CGA with embedded IPv4 
address. We are working on this issue now.
(4) According to our experience of implementing the IVI translator, 
there is no serious consequence when u-bit/g-bit rule is not applied. 
However, as stated in (1), we can update the stateless address mapping 
algorithm.

Regards,

xing

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 20 Jul 2009 16:56:56 +0200

> source cannot spoof such traffic.

This can arguably be useful if the first packet originates from the  
real or fake NAT64. But that would be rare, the first packet comes  
from the client host. If this host can be tricked into sending packets  
to the fake NAT64, there's not much point in doing a CGA check for the  
return traffic: even if the client knows the traffic is fake the fact  
that the traffic was directed to the fake NAT64 in the first place  
creates a successful denial of service.

---

From: Dave Thaler <[email-masked]>
Date: Mon, 20 Jul 2009 16:55:36 +0000

> Sent: Monday, July 20, 2009 7:57 AM
> To: Dave Thaler

Sounds like we're in sync now.  We agree it can be arguably useful
in cases that may not be important, because of the vulnerabilities
that still exist on the IPv4 side.

-Dave