Subject: [Softwires] Limitation of "4V6 Translation" between sites of the same domain

From: Rémi Després <[email-masked]>
Date: Tue, 19 Jul 2011 10:55:58 +0200

Hi, all,

1.
The translation-based stateless solution for IPv4 via IPv6 described in draft-murakami-softwire-4v6-translation-00 seems to have a significant limitation:
- When a 4V6T customer-edge node receives a packet from a CE of the same 4V6T domain, it doesn't know whether it must treat it as a native IPv6 packet from this CE or as an IPv4 packet that this CE has translated. 

        <-- 4V6T domain -->   <-- IPv4 Internet --

(A) 4V6T CE |---->----.
                      |
                      V---- 4v6T-BR --- - - - 
                      |
(B) 4V6T CE |----<----'
        <= v4 or v6 ??

For instance, if the IPv4 address of (B) is shared, (B) doesn't know whether received packets must go to its internal NAT44, or be treated a real IPv6 packet.
(Sending to the NAT44 packets whose ports are currently bound in the NAT44 wouldn't be satisfactory: all ports may be used in IPv6).

2.
Note that this problem doesn't apply to the encapsulation-based stateless solution (4V6E):
- A 4V6E CE treats a received IPv6 packet as containing an IPv4 packet if, and only if, its Next header is IP-in-IP, and the encapsulated packet is IPv4. There is no ambiguity.

=> Unless something is wrong in the above, or a palliative is devised, consideration of this should be added to the comparative analysis of 4V6T and 4V6E solutions (draft-dec-stateless-4v6).

Regards,
RD

---

From: GangChen <[email-masked]>
Date: Wed, 20 Jul 2011 00:53:49 +0800

Hello Remi,

I guess 4V6 CE need to recognize whether received IPv6 prefix is CE
IPv6 prefix, which is used to generate a shared IPv4 address. Then, it
should be no problem to distinguish native IPv6 or an IPv6 address CE
should translated.

Gang

2011/7/19, Rémi Després <[email-masked]>:
> Hi, all,
>
> 1.
> The translation-based stateless solution for IPv4 via IPv6 described in
> draft-murakami-softwire-4v6-translation-00 seems to have a significant
> limitation:
> - When a 4V6T customer-edge node receives a packet from a CE of the same
> 4V6T domain, it doesn't know whether it must treat it as a native IPv6
> packet from this CE or as an IPv4 packet that this CE has translated.
>
>
> For instance, if the IPv4 address of (B) is shared, (B) doesn't know whether
> received packets must go to its internal NAT44, or be treated a real IPv6
> packet.
> (Sending to the NAT44 packets whose ports are currently bound in the NAT44
> wouldn't be satisfactory: all ports may be used in IPv6).
>
> 2.
> - A 4V6E CE treats a received IPv6 packet as containing an IPv4 packet if,
> and only if, its Next header is IP-in-IP, and the encapsulated packet is
> IPv4. There is no ambiguity.
>
> => Unless something is wrong in the above, or a palliative is devised,
> consideration of this should be added to the comparative analysis of 4V6T
> and 4V6E solutions (draft-dec-stateless-4v6).
>
>
> Regards,
> RD
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires
>

---

From: Tetsuya Murakami <[email-masked]>
Date: Tue, 19 Jul 2011 12:18:15 -0700

Hi Remi,

In terms of 4via6 translation, 4via6 CE can process the received IPv6 packets if the IPv6 destination address is the tunnel end-point address which is assigned to that 4via6 CE and also the IPv6 source address is the IPv4-embedded IPv6 address which is defined in RFC6052. If these condition of IPv6 source and destination address is not matched, 4via6 CE can process the received IPv6 packets as the normal IPv6 packet. So, I don't think there is no issue which you raised.

Thanks,
Tetsuya Murakami

---

From: Rémi Després <[email-masked]>
Date: Wed, 20 Jul 2011 09:24:10 +0200

Le 19 juil. 2011 à 18:53, GangChen a écrit :

> IPv6 prefix, which is used to generate a shared IPv4 address.

You apparently assume that the receiving CE has two IPv6 prefixes, with one reserved for shared IPv4 addresses.
This is possible but, AFAIK, isn't required in 4V6T (and isn't needed in 4V6E).

If 4V6T CE's would be required to have two IPv6 prefixes (or as a minimum two different addresses), this would become an operational constraint to be considered when comparing the two solutions.

Regards,
RD
  
> Then, it

---

From: Rémi Després <[email-masked]>
Date: Wed, 20 Jul 2011 09:28:12 +0200

Le 19 juil. 2011 à 21:18, Tetsuya Murakami a écrit :

> Hi Remi,
> 
> In terms of 4via6 translation, 4via6 CE can process the received IPv6 packets if the IPv6 destination address is the tunnel end-point address which is assigned to that 4via6 CE and also the IPv6 source address is the IPv4-embedded IPv6 address which is defined in RFC6052. If these condition of IPv6 source and destination address is not matched, 4via6 CE can process the received IPv6 packets as the normal IPv6 packet.

Then if CE A sends an IPv6 packet to CE B, it will be processed there as a received IPv4 packet.
Right?
(Please, see also my answer to Gang.)

Regards,
RD

> So, I don't think there is no issue which you raised.
> 
> Thanks,
> Tetsuya Murakami
>

---

From: Jacni Qin <[email-masked]>
Date: Wed, 20 Jul 2011 16:53:50 +0800

hi Remi,

On Wed, Jul 20, 2011 at 3:28 PM, Rémi Després <[email-masked]>wrote:

> > In terms of 4via6 translation, 4via6 CE can process the received IPv6
> packets if the IPv6 destination address is the tunnel end-point address
> which is assigned to that 4via6 CE and also the IPv6 source address is the
> IPv4-embedded IPv6 address which is defined in RFC6052. If these condition
> of IPv6 source and destination address is not matched, 4via6 CE can process
> the received IPv6 packets as the normal IPv6 packet.
>

Jacni>: You mean the CE IPv6 prefix also serves the native IPv6 users on the
LAN side, right? That's not yet been clearly stated, I just found in the 4rd
draft, Introduction section,
"On the "end-user-facing" (i.e., "LAN") side of a CE, IPv6 and IPv4 are
implemented as for any native dual-stack service delivered by the SP. "

Cheers,
Jacni

> >>> Note that this problem doesn't apply to the encapsulation-based
> stateless
> >>> solution (4V6E):

---

From: Rémi Després <[email-masked]>
Date: Wed, 20 Jul 2011 13:34:48 +0200

Le 20 juil. 2011 à 10:53, Jacni Qin a écrit :

> hi Remi,
> 
> On Wed, Jul 20, 2011 at 3:28 PM, Rémi Després <[email-masked]> wrote:
> 
> Jacni>: You mean the CE IPv6 prefix also serves the native IPv6 users on the LAN side, right? That's not yet been clearly stated, I just found in the 4rd draft, Introduction section,
> "On the "end-user-facing" (i.e., "LAN") side of a CE, IPv6 and IPv4 are implemented as for any native dual-stack service delivered by the SP. "

Yes.
For the LAN to have a global IPv6 prefix, it has to use that which is assigned to the site, i.e. to the CE.
OK?

RD

---

From: Wojciech Dec <[email-masked]>
Date: Wed, 20 Jul 2011 13:45:11 +0200

Hello Remi,

Good question. Thankfully, this is not an issue as answered in
Sections 5.4 and 5.5 (and briefly in 5.2) of draft-dec-stateless-4v6,
since CPE A would not send non-v4 traffic (e.g. native IPv6 traffic)
to CPE-B's 4V6 address.

Allow me to expand, along with giving some background

0. The IPv6 4V6 prefix assigned to the CPE is, say, a /64. The CPE
thus may use the same /6r prefix to calculate the 4V6 address, using
4V6 domain parameters, as well as other IPv6 addresses in that prefix
using SLAAC, say.   As an example: When a suitable 4V6 /64 prefix is
advertised in an RA, a 4V6 CPE will configure itself both a 4V6
interface address and a SLAAC address. A similar case applies when
DHCP-PD is used.

1. ALL 4V6 systems, without distinction between translation or
encapsulation mode, need to use the specific 4V6 IPv6 interface
address for their stateless 4V6 function - no other address will do
for stateless operation (BTW some may like to call the 4V6 interface a
virtual interface).

2. In general, a 4V6 CPE working in translation mode will pass to
NAT44 all traffic arriving on the IPv6 4V6 interface -  while an
encapsulating 4V6 system will pass to NAT44 all encapsulated IPv4
traffic arriving on the IPv6 4V6 interface. In both cases there are
restrictions on what can be done on/with the 4V6 interface. Some
implementation considerations come to the fore, such as the fact that
4V6 is intended to be a custom CPE function and not a user application
on a generic host, ie The CPEs kernel typically needs to support 4V6,
and all the above can be accomplished optimally.

3. Traffic originating from IPv6 hosts behind the CPE or sourced by
IPv6 apps on the 4V6 CPE itself will use a non 4V6 address as their
source address, but from the 4V6 prefix (or its subnet). Hence there
is no ambiguity with handling any such IPv6 return traffic.

Regards,
Wojtek.

---

From: Wojciech Dec <[email-masked]>
Date: Wed, 20 Jul 2011 13:37:01 +0200

Hello Remi,

Good question. Thankfully, this is not an issue as answered in Sections 5.4
and 5.5 (and briefly in 5.2) of draft-dec-stateless-4v6, since CPE A would
not send non-v4 traffic (e.g. native IPv6 traffic) to CPE-B's 4V6 address.

0. The IPv6 4V6 prefix assigned to the CPE is, say, a /64. The CPE thus may
use the same /6r prefix to calculate the 4V6 address, using 4V6 domain
parameters, as well as other IPv6 addresses in that prefix using SLAAC, say.
As an example: When a suitable 4V6 /64 prefix is advertised in an RA, a 4V6
CPE will configure itself both a 4V6 interface address and a SLAAC address.
A similar case applies when DHCP-PD is used.

1. ALL 4V6 systems, without distinction between translation or encapsulation
mode, need to use the specific 4V6 IPv6 interface address for their
stateless 4V6 function - no other address will do for stateless operation
(BTW some may like to call the 4V6 interface a virtual interface).

2. In general, a 4V6 CPE working in translation mode will pass to NAT44 all
traffic arriving on the IPv6 4V6 interface -  while an encapsulating 4V6
system will pass to NAT44 all encapsulated IPv4 traffic arriving on the IPv6
4V6 interface. In both cases there are restrictions on what can be done
on/with the 4V6 interface. Some implementation considerations come to the
fore, such as the fact that 4V6 is intended to be a custom CPE function and
not a user application on a generic host, ie The CPEs kernel typically needs
to support 4V6, and all the above can be accomplished optimally.

3. Traffic originating from IPv6 hosts behind the CPE or sourced by IPv6
apps on the 4V6 CPE itself will use a non 4V6 address as their source
address, but from the 4V6 prefix (or its subnet). Hence there is no
ambiguity with handling any such IPv6 return traffic.

Regards,
Woj.

On 19/07/2011 10:55, "Rémi Després" <[email-masked]> wrote:

> - When a 4V6T customer-edge node receives a packet from a CE of the same 4V6T
> domain, it doesn't know whether it must treat it as a native IPv6 packet from
> this CE or as an IPv4 packet that this CE has translated.
> 
> 
> - A 4V6E CE treats a received IPv6 packet as containing an IPv4 packet if, and
> only if, its Next header is IP-in-IP, and the encapsulated packet is IPv4.
> There is no ambiguity.
> 
> consideration of this should be added to the comparative analysis of 4V6T and
> 4V6E solutions (draft-dec-stateless-4v6).
> 
> 
> Regards,
> RD

---

From: Rémi Després <[email-masked]>
Date: Wed, 20 Jul 2011 15:06:52 +0200

> ambiguity with handling any such IPv6 return traffic.

Thanks, Wojciech, for the explanation.

Sec 5.5 indeed says "A 4V6 CE will have a "self configured" 4V6 IPv6 interface address, alongside any other SLAAC or DHCPv6 derived addresses, potentially from the same prefix." 
But it remains that the "self-configured" 4V6 address looks like a valid SLAAC or DHCPv6 assigned address.

In my understanding, the problem is that a receiving CE cannot make the difference:
- between a source 4V6 address coming from a 4v6 CE and one coming from a non-4V6 CE
- between its CE 4V6 address and a real IPv6 destination starting with the assigned IPv6 prefix
With "4V6 Encapsulation", making these differences is unnecessary, but with "4V6 Translation" a safe way to recognize IPv4 packets is AFAIK missing.

Regards,
RD

---

From: Wojciech Dec <[email-masked]>
Date: Wed, 20 Jul 2011 16:20:48 +0200

Hello Remi,

> But it remains that the "self-configured" 4V6 address looks like a valid SLAAC or DHCPv6 assigned address.

Well, what it is, and what it looks like is *an IPv6 address* and it
is valid, and it is in the 4V6 prefix, so I don't quite see what is
the issue you're making out. Are you perhaps thinking of a prefix as
being a single address?

> With "4V6 Encapsulation", making these differences is unnecessary, but with "4V6 Translation" a safe way to recognize IPv4 packets is AFAIK missing.

As per items 1, 2 and 3 above; the CPE does NOT need to make the
distinction you make out. If packets are sent to that address, they
get passed to NAT44. Hosts behind the CPE or apps on the CPE will not
use/bind to that address.

Regards,
Woj.

---

From: Rémi Després <[email-masked]>
Date: Wed, 20 Jul 2011 16:57:30 +0200

Le 20 juil. 2011 à 16:20, Wojciech Dec a écrit :

>> ...
> is valid, and it is in the 4V6 prefix,

That's what I meant:
Although the 4V6 address was obtained neither with SLAAC nor with DHCPv6, it can't be distinguished from an ordinary SLAA-C of DHCPv6-obtained address. 

> so I don't quite see what is

NO (?!)

> distinction you make out. 

> If packets are sent to that address, they

AFAIK, this prohibits using the full CE-assigned IPv6 on the CE LAN side.
Such a constraint isn't needed with "4V6 encapsulation".

RD

---

From: Wojciech Dec <[email-masked]>
Date: Wed, 20 Jul 2011 18:02:40 +0200

> Although the 4V6 address was obtained neither with SLAAC nor with DHCPv6, it can't be distinguished from an ordinary SLAA-C of DHCPv6-obtained address.

It is an IPv6 address, granted. There is however something special
about it, as per the 4rd spec. It has a well known IID, and in effect
becomes a kind of well-known address.

> Such a constraint isn't needed with "4V6 encapsulation".

No. A 4v6 prefix can be advertised out of the CE LAN, and an fully
formed address (eg SLAAC) from it assigned.
In fact, the 4V6 address can be "wherever" on the CPE should you
choose to implement it that way - how you do this is subject to CPE
implementation. Just as it is implementation specific how you dictate
the 4V6 function to source packets from that address, and how you
prevent some other CPE based process that wants to use IPv6 from using
that 4v6 address (eg another process that also wants to use IPinIP
encap, or whatever).
Yes, there is a difference when implementing the tunneling and the
translation modes on the CPE - that's stating the obvious if you ask
me, but point taken, I will remark on this in the draft.

-Woj.

---

From: Wojciech Dec <[email-masked]>
Date: Wed, 20 Jul 2011 18:25:41 +0200

Correcting typo and truncated sentence.

On 20 July 2011 18:02, Wojciech Dec <[email-masked]> wrote:
> No. A 4v6 prefix can be advertised out of the CE LAN, and any fully
> formed address (eg SLAAC) from it assigned to the CE's LAN or host.

---

From: Rémi Després <[email-masked]>
Date: Thu, 21 Jul 2011 11:06:37 +0200

>> No.

A justification of this "no" is missing, because:
- The CE 4V6 address is synonymous with a valid IPv6 address in the range defined by the CE IPv6 prefix.
- With 4V6T, a translated IPv4 packet entering a 4V6 site cannot be distinguished from an IPv6 packet destined to this valid IPv6 address.

An example:

Host 
 H
+-+                router
| |< 2001:db8:a::  
| |--------------.  .-.
| |              |  | |< 2001:db8:a::/64   4V6T CE
+-+         LAN  |--| |-----------------.   +-+
                 |  | |                 |   | |< 2001:db8:a:/56 
   --------------'  '-'           LAN   |---| |------------
                                        |   +-+  <= IPv6 packet
                        ----------------'         sent to host H

- The IPv6 address of host H has a permitted value (at least per sec 3.2.1 of RFC 3041 on privacy addresses).
- It is the same as the CE 4V6 address, per current drafts on 4V6 specifications.
=> The IPv6 packet sent to X form the Internet is taken by the 4V6T CE as a translated IPv4 packet.
   It is submitted to the CE NAT44.
   It won't therefore reach its destination.

With a 4V6E CE, the CE recognizes that the IPv6 packet doesn't contain an encapsulated IPv4 packet.
It therefore forwards it in IPv6 on its LAN side.

If this is wrong, thank you for an explanation.

RD

---

From: Wojciech Dec <[email-masked]>
Date: Thu, 21 Jul 2011 11:30:24 +0200

> A justification of this "no" is missing, because:

It's not missing. Please do read once more the rest of the mail, as
well as those of others.

> - With 4V6T, a translated IPv4 packet entering a 4V6 site cannot be distinguished from an IPv6 packet destined to this valid IPv6 address.

No.
The above indicates some confusion between a prefix and an address
Aside from the fact that Host H above has an address that is clearly
not derived via SLAAC (not to mention very bogus in the context of
rfc3041), on the above link you either have TWO/THREE(?) devices with
the same IP address (2001:db8:a::) all on different links, or the 4V6
routers without any address. In either case the set-up is not correct
(or at least your model set-up is the problem).

Thanks,
Woj.

---

From: Rémi Després <[email-masked]>
Date: Thu, 21 Jul 2011 12:21:20 +0200

Le 21 juil. 2011 à 11:30, Wojciech Dec a écrit :

> rfc3041),

> on the above link you either have TWO/THREE(?) devices with
> the same IP address (2001:db8:a::)

Not two or three! Just one.
Having a delegated prefix at an interface (e.g. < 2001:db8:a::/64) doesn't mean that this prefix is the interface address, does it? 
Confusing prefixes, like 2001:db8:a::/64), and addresses, like  2001:db8:a::, seems to be what YOU did, not me ;-).

As you know, we both agreed, in an of-list discussion, that the IID of 4V6 addresses would better be a 1 than a 0. 
This would avoid, as you pointed out, a conflict the IID of the Subnet-Router anycast address of RFC 4291. 
This being done, replace the host address by 2001:db8:a::1, and the example holds better.

If the IID of 4V6 addresses is not permitted on a link, the 4V6 CE's could be difficult to reach from the Internet.
If it is a permitted one, a host behind the CE may have this IID.

Regards,
RD

> all on different links, or the 4V6

---

From: Wojciech Dec <[email-masked]>
Date: Thu, 21 Jul 2011 12:37:00 +0200

> Confusing prefixes, like 2001:db8:a::/64), and addresses, like  2001:db8:a::, seems to be what YOU did, not me ;-).

Your diagram says otherwise, as it shows the routers either without an
IP address, or with bogus subnetting (subnet 0 cannot be in two
places/links). Good luck with making the set-up work in any case.
> If it is a permitted one, a host behind the CE may have this IID.

Indeed, and what you seem to be trying very hard to say is that
building an IPv6 network where multiple IPv6 devices have *the same*
IPv6 address is ok and reasonable, and will somehow work unambiguously
with the encapsulated mode... Interesting... In general, this is known
as an IPv6 addressing violation/conflict, and there are specific
procedures to prevent that for good reason.

Thanks,
Woj.

---

From: Rémi Després <[email-masked]>
Date: Thu, 21 Jul 2011 17:00:09 +0200

Wojciech,

Le 21 juil. 2011 à 12:37, Wojciech Dec a écrit :

(with my typos corrected)

> ... Your diagram (...) shows the routers either without an

> places/links).

The picture doesn't show a router IP address because it was unnecessary for the explanation, but this doesn't imply there is none (everybody knows that each interface must have at least one address!).

Similarly, the picture doesn't show the subnet ID of the rightmost LAN, but this by no means imply that it should be 0 (everybody knows that all links that have global link prefixes must have them with different values).
 
If the new picture below is insufficiently clear, please ask, rather than making interpretations that don't make sense, and then objecting to them.

>> ... As you know, we both agreed, in an off-list discussion, that the IID of 4V6 addresses would better be a 1 than a 0 ...

Here is now a more complete example (with 1 as IID of 4V6 addresses in view of the above) 

==============
Host              router                    CE

+-+ Interface address  Interface address
| |< 2001:db8:a::1     < 2001:db8:a:ffff::10
| |--------------.  .-. Delegated prefix        Interface address
| |              |  | |< 2001:db8:a::/64        < 2001:db8:0:a:4:5:6:7 
+-+              |--| |-----------------.   +-+ Assigned IPv6 prefix
                 |  | |                 |   | | < 2001:db8:a::/48 
                 |  '-'                 |---| |------------
          LAN-2  |                      |   +-+  
        Link prefix                     |        <= packet X (IPv6)  
    2001:db8:a::/64               LAN-1 |        <= packet Y (IPv4-in-IPv6)
                               Link prefix    IPv6 destinations=2001:db8:a::1
                      2001:db8:a:ffff::/64             

Both packets X (IPv6) and Y (IPv4-in-IPv6) reach the CE because of their IPv6 destinations start with the CE assigned prefix 2001:db8:a::/48. 
Now:
- If the CE is 4V6T, how packet X reaches the host is unclear to me. 
- If the CE is 4V6E, 
  . Packet X is submitted to ordinary IPv6 routing because its payload IS NOT an IPv4 packet.  
  . Packet Y has its contents directly submitted to the CE NAT44 because its payload IS an IPv4 packet. (The 4V6 address 2001:db8:a::1, never treated as a destination on any IPv6 link, is in fact a "dummy address".)
===============

An explanation of how 4V6T can work, on a configuration as detailed as this one, would be welcome.
It would help to reach common understanding.

Regards,
RD

---

From: Wojciech Dec <[email-masked]>
Date: Thu, 21 Jul 2011 19:27:25 +0200

>  . Packet Y has its contents directly submitted to the CE NAT44 because its payload IS an IPv4 packet. (The 4V6 address 2001:db8:a::1, never treated as a destination on any IPv6 link, is in fact a…

Please describe what you mean by an IPv6 "dummy address", or where can
one find it described?
In your model you seem to have an address on the 4V6 CE. This address,
whatever you want to call it is either a duplicate address (somehow
host H has it too) or an anycast address (that again somehow host H
ended up with). On top of that somehow the CE is able to ignore
regular IPv6 local/forward processing rules by looking at the payload
(whether is IPinIP or not). Apart from this being rather far fetched,
how does that line up with native IPv6 forwarding that you claim to be
at issue here?

Oh, one other thing: Say that IPv6 Host H was actually running an
IPinIP tunnel/application and wants to receive such traffic. How does
the model you describe work then?

Thanks,
Woj.

PS In terms of exotic set-ups, I'm sure we can find plenty of other
ones. This does not change the fact that in the S46 set-up with the
characteristics as outlined in my initial reply, without system
elements having duplicate IPv6 addresses, the problem you mention does
not appear in neither translation nor tunneling modes.

---

From: Rémi Després <[email-masked]>
Date: Fri, 22 Jul 2011 12:20:04 +0200

Le 21 juil. 2011 à 19:27, Wojciech Dec a écrit :
...
> Please describe what you mean by an IPv6 "dummy address", or where can

OK, ignore the "dummy address" bit.
(The behavior is AFAIK clear, with no need for a new name.)

Let's now be constructive, with solutions.

> the model you describe work then?

OK, that's a good point: if hosts behind a 4V6 CE are permitted to have any addresses that start with the CE assigned IPv6 prefix, a host whose address is the same as the specified 4V6 address won't be able to do  IPv4 in IPv6 tunneling per RFC 2473.

SOLUTION:
This is easily avoided if the 4V6E encapsulation is done with a Protocol number different from 41. 
Since Protocol 41 is in IANA for point-to-point tunnels of RFC 2473, it makes sense to have a new one for stateless multipoint tunnels.

> ... in the S46 set-up with the

OK, but the setup of your initial reply is only for CE's being assigned a /64, which imposes a single LAN-side link. Shorter IPv6 prefixes assigned to multiple-link sites lead to more complex analysis. 

SOLUTION: 
If the IID of 4V6 addresses is one that never needs to be assigned to work in IPv6, which isn't difficult to ensure, no conflict is possible between a hosts IPv6 address and a 4V6 address.

A possible IID value is that of an embedded IPv4 address (as in ISATAP), with a reserved IPv4 address that no network would use.
If this address is 0.0.0.0, the 4V6 IID is 0:5efe:0:0. 
(If a completely new address is preferred,it could for instance be 192.0.0.0, to be registered by IANA to mean "unspecified IPv4 address", the equivalent of :: in IPv6. 

Both solutions are AFAIK extremely simple, and do solve the two issues.
I hope they will be looked at constructively.

Regards,
RD

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 22 Jul 2011 14:44:39 -0700 (PDT)

I wanted to write to my 4rd friends that I think that CE is not the right term 
to use and would suggest using Customer Edge (CE) router instead. This is what 
RFC 6204 uses and is consistent with BBF terminology. So use CE router anywhere 
instead of CE.

--b

> >>  . Packet Y has its contents directly submitted to  the CE NAT44 because its 
>payload IS an IPv4 packet. (The 4V6 address  2001:db8:a::1, never treated as a 
>destination on any IPv6 link, is in fact a  "dummy address".)
> >> ===============
> > 
> OK, that's a good  point: if hosts behind a 4V6 CE are permitted to have any 
>addresses that start  with the CE assigned IPv6 prefix, a host whose address is 
>the same as the  specified 4V6 address won't be able to do  IPv4 in IPv6 
>tunneling per RFC  2473.
> 
> SOLUTION:
> Since Protocol 41 is in IANA  for point-to-point tunnels of RFC 2473, it makes 
>sense to have a new one for  stateless multipoint tunnels.
> 
> 
> OK,  but the setup of your initial reply is only for CE's being assigned a /64, 
>which  imposes a single LAN-side link. Shorter IPv6 prefixes assigned to 
>multiple-link  sites lead to more complex analysis. 
>
> 
> SOLUTION: 
> If the IID of 4V6  addresses is one that never needs to be assigned to work in 
>IPv6, which isn't  difficult to ensure, no conflict is possible between a hosts 
>IPv6 address and a  4V6 address.
> 
> A possible IID value is that of an embedded IPv4 address (as  in ISATAP), with 
>a reserved IPv4 address that no network would use.
> (If a completely new address  is preferred,it could for instance be 192.0.0.0, 
>to be registered by IANA to  mean "unspecified IPv4 address", the equivalent of 
>:: in IPv6. 
>
> 
>

---

From: Rémi Després <[email-masked]>
Date: Sat, 23 Jul 2011 17:13:59 +0200

Hi, all,

One remark, and one correction, about this recent email:

Remark:
If the second solution below is adopted (4V6-specific IID in 4rd-4V6 IPv6 addresses), the first solution (4V6-specific protocol number) is no longer necessary.
However, it  better separates functions, and makes no harm.
The suggestion remains therefore to adopt both solutions (but I have no objection if only the second is adopted).

Correction:
The proposed 4V6 IID (ISATAP based with null IPv4 address), because it is globally unique, must have its "u" bit has to be 1 (ref sec. 6.1 of RFC 5214).
It is then 20:5efe:0:0.
(This is in fact what ensures that this IID differs from all non-globally-unique IID's that hosts are permitted to have.) 

Regards,
RD