Subject: [Softwires] Proposed Unified Address Mapping for encapsulation and double-translation

From: Rémi Després <[email-masked]>
Date: Tue, 4 Oct 2011 12:22:05 +0800

Hi all,

1.
Here is a unified Address Mapping, for both encapsulation and double-translation approaches, that is PROPOSED for IPv4 residual deployment across IPv6-only routing domains.

It results from an informal meeting among participants having different preferences between double-translation and encapsulation solutions (Xing Li, Congxiao Bao, Wojciech Dec, myself, at the end of the Beijing meeting).

The idea is to have a common format that is good for both types of solutions.
In particular:
- It enriches Double translation by introducing a deterministic way to distinguish a translated IPv4 packet from a native IPv6 packet.
- It enriches Encapsulation by expressing, in clear format within an IPv6 address, an IPv4 address, an IPv4 prefix, or an IPv4 address + port-set ID. 

2.
(a)
The IPv6 Source address of an IPv4 packet from a CE is:

a1- If the CE has an exclusive or shared IPv4 address:

<--------- 64 ------------><8 ><------ L >= 32 -------><48-L><8 >
+-------------+--------+---+---+----------------+------+-----+---+
| IPv6 prefix |CE index| 0 | V |  IPv4 address  | PSID |  0  | L |
+-------------+--------+---+---+----------------+------+-----+---+

a2- If the CE has an IPv4 prefix:

<--------- 64 ------------><8 ><-- L < 32 --><--- 48-L -----><8 >
+-------------+--------+---+---+-------------+---------------+---+
| IPv6 prefix |CE index| 0 | V | IPv4 prefix |         0     | L |
+-------------+--------+---+---+-------------+---------------+---+

(b)
V is the mark that characterizes IPv6 packets that are in reality IPv4 packets.
Its value differs from any permitted value of this octet in IPv6 IIDs  (ref RFC 4291).

It is understood that, if double Translation coexists with single translation, concerned ISPs may notify their CEs to use the U octet of RFC 6052 instead of V.

An unambiguous mark is fortunately possible because currently permitted IIDs have in their first octet either bit6 = 0 (the "u" bit"), or bit6 = 1 and bit7= 0 (the "g" bit).
With V having "u" = 1 (signifying Universal scope) AND "g" = 1, distinction is therefore deterministic.

The proposed V is = 00000011. 
(With other values of this octet, other IID formats can be defined in case some would be useful in the future.)

Note that, if and when a consensus is reached in Softwire, an extension of RFC 4291 will have to be submitted to 6MAN. 

(c)                                   
A Destination address from a CE to the outside IPv4 Internet is:
<--------- 64 ------------>< 8 ><----   32 ----><--- 16 ----><8 >
+--------------------------+----+---------------+------------+---+
|     BR subnet prefix     | V  |  IPv4 address |      0     |32 |
+--------------------------+----+---------------+------------+---+

Note that if double-translation CEs are notified to use U instead of V, the last octet becomes 0 per RFC  6052.

3.
All comments are most welcome.
  
Kind regards to all,
RD

---

From: GangChen <[email-masked]>
Date: Wed, 5 Oct 2011 01:10:02 +0800

Hello Remi,

I'm trying to put some comments for such unified address mapping.
Regarding the deterministic benefit for double translation, I guess we
only could use V bits to achieve.
There are no necessary to put IPv4 and Port-set ID information in last
64 bits.
If I understand correctly, the encoded IPv4 and Port-set ID could help
to derive a shared/dedicated IPv4 address or IPv4 subnet from the IPv6
prefix.
It may help encapsulation in same cases(e.g. IPv4 based traffic
classification,IPv4 ACL, etc).
However, the translation case is more preferable doing pure IPv6 based
control for the sake of simpler operation reasons (e.g. IPv6 ACL).
It's desirable identifying a customer depending on first 64 bits.

Many thanks

Gang

2011/10/4, Rémi Després <[email-masked]>:
> Hi all,
>
> 1.
> Here is a unified Address Mapping, for both encapsulation and
> double-translation approaches, that is PROPOSED for IPv4 residual deployment
> across IPv6-only routing domains.
>
> It results from an informal meeting among participants having different
> preferences between double-translation and encapsulation solutions (Xing Li,
> Congxiao Bao, Wojciech Dec, myself, at the end of the Beijing meeting).
>
> - It enriches Double translation by introducing a deterministic way to
> distinguish a translated IPv4 packet from a native IPv6 packet.
> - It enriches Encapsulation by expressing, in clear format within an IPv6
> address, an IPv4 address, an IPv4 prefix, or an IPv4 address + port-set ID.
>
>
> 2.
> (a)
> It is understood that, if double Translation coexists with single
> translation, concerned ISPs may notify their CEs to use the U octet of RFC
> 6052 instead of V.
>
> An unambiguous mark is fortunately possible because currently permitted IIDs
> have in their first octet either bit6 = 0 (the "u" bit"), or bit6 = 1 and
> bit7= 0 (the "g" bit).
> Note that, if and when a consensus is reached in Softwire, an extension of
> RFC 4291 will have to be submitted to 6MAN.
>
> (c)
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires
>

---

From: Rémi Després <[email-masked]>
Date: Wed, 5 Oct 2011 09:34:18 +0800

Hi Gang,

Thanks for your comments.
More below.

> only could use V bits to achieve.

Right.
V is indeed a reliable tool for this.

> There are no necessary to put IPv4 and Port-set ID information in last

The CE Pv6 prefix included in the /64 Subnet prefix isn't self delimited, so that the length of the CE index can't be determined in this part of the address. 
Having the length of the A or A+P prefix in the IID completes what is needed to derive the CE port-set.

> to derive a shared/dedicated IPv4 address or IPv4 subnet from the IPv6

Yes.
Besides, having the IPv4 address (or prefix) in clear form, and with an explicit sharing ratio, facilitates maintenance at essentially no cost. 

> It's desirable identifying a customer depending on first 64 bits.

A point is that, although some realistic deployments may ignore what is made available in IIDs (at least at the beginning), some others would take advantage of it.
A standard with a straightforward and unified format is AFAIK better than several variants, at least for documentation, training, maintenance etc.

Note also that even with a single standard, it remains possible to add optional variants if found useful for some deployments.

Hope it clarifies.

Regards,
RD

---

From: Congxiao Bao <[email-masked]>
Date: Wed, 5 Oct 2011 17:42:51 +0800

Hi,

2011/10/5 Rémi Després <[email-masked]>

> V is indeed a reliable tool for this.

If ISP wants to use a single IPv6 prefix for double translation and
Encapsulation, V mark is need.

> The CE Pv6 prefix included in the /64 Subnet prefix isn't self delimited,
> so that the length of the CE index can't be determined in this part of the
> address.

Besides, if a medium or large size ISP can’t get short enough IPv6 prefix
(ex. /24), the first 64 bits can not contain the whole IPv4 32 bits, which
cannot make the double translation successful.

> Besides, having the IPv4 address (or prefix) in clear form, and with an
> explicit sharing ratio, facilitates maintenance at essentially no cost.
>

Agree. Having whole IPv4 address in clear form is very critical for
operation, like IPv6 ACL.

> A point is that, although some realistic deployments may ignore what is
> made available in IIDs (at least at the beginning), some others would take
> advantage of it.
> A standard with a straightforward and unified format is AFAIK better than
> several variants, at least for documentation, training, maintenance etc.
>
> Note also that even with a single standard, it remains possible to add
> optional variants if found useful for some deployments.
>

The ISP is not able to achieve per-host traffic control without a standard
defining last 64 bits. If the ISP does, why not use IPv4+psid in suffix
naturally instead of other new bits definition?

Best,

Congxiao

> >> Its value differs from any permitted value of this octet in IPv6 IIDs
>  (ref
> >> RFC 4291).
> >>
> >> With V having "u" = 1 (signifying Universal scope) AND "g" = 1,
> distinction
> >> is therefore deterministic.
> >>
> >> (With other values of this octet, other IID formats can be defined in
> case
> >> some would be useful in the future.)
> >>
> >> Note that if double-translation CEs are notified to use U instead of V,
> the
> >> last octet becomes 0 per RFC  6052.
> >>
> >>
> >> 3.

---

From: Qiong <[email-masked]>
Date: Wed, 5 Oct 2011 22:45:00 +0800

Hi, Remi,

Thanks for your effort. I think this is a big progress after the Interim
meeting, and this unified address format is quite clear now. Here, I have
two comments after a quick review. And I will get back to you if I have more
comments later.

1. With regard to destination address format, if I understand correctly, it
only covers hub&spoke model with a default "BR subnet prefix". Are you
intended to propose another format for mesh one ? Or just cite the "Source
address format" as the destination address in MESH situation. I think it
would be better to declare it separately for "H&S" and "MESH". This would be
more clearer for readers to understand different situations.

2. Still for the destination address format, I suggest to embed PSID as well
in the lower 64 bits (as in the following).

<--------- 64 ------------>< 8 ><----   32 ----><--- 16 ----><8 >
+--------------------------+----+---------------+------------+---+
|     BR subnet prefix     | V  |  IPv4 address  | PSID |  0  | L |
+--------------------------+----+---------------+------------+---+

This would make it easier for in-the-middle systems(e.g. BNG) to do prefix
mapping without packet decapsulation. And this is quite similar to the
source address format. What do you think of it?

Best wishes

Qiong

On Tue, Oct 4, 2011 at 12:22 PM, Rémi Després <[email-masked]>wrote:

> An unambiguous mark is fortunately possible because currently permitted
> IIDs have in their first octet either bit6 = 0 (the "u" bit"), or bit6 = 1
> and bit7= 0 (the "g" bit).

---

From: GangChen <[email-masked]>
Date: Thu, 6 Oct 2011 06:01:59 +0800

Hello Remi,

Thanks for the answers.
Please see my reply inline.

2011/10/5, Rémi Després <[email-masked]>:
> The CE Pv6 prefix included in the /64 Subnet prefix isn't self delimited, so
> that the length of the CE index can't be determined in this part of the
> address.

I understand such encoded information helps deriving a shared IPv4
address. However, I guess it's not necessary to dig up such
information if we only take traffic contronl on IPv6 data plane (as I
said below)

> A point is that, although some realistic deployments may ignore what is made
> available in IIDs (at least at the beginning), some others would take
> advantage of it.

Yes. I agree with your point here. As you said such IID design may not
be taken effect on some realistic deployments, I would like to suggest
the IID MAY not appeared in double translation cases.

Many thanks

Gang

---

From: GangChen <[email-masked]>
Date: Thu, 6 Oct 2011 06:14:52 +0800

Hello Congxiao,

Thanks for the discussion.
Please see my reply inline.

> cannot make the double translation successful.

I guess that is depending on a specific algorithm. I don't see such
limitation in 4v6
translation(http://tools.ietf.org/html/draft-murakami-softwire-4v6-translation-00)

> operation, like IPv6 ACL.

Could you kindly help elaborating why this is critical for IPv6 ACL?

> naturally instead of other new bits definition?

First off, I'm not sure per-host traffic control is a common case for
network operations
Secondly, it could be possible to use first 64 bits differentiating
hosts. Please see Max PSID usage in
http://tools.ietf.org/html/draft-despres-softwire-4rd-addmapping-01#page-15

Many thanks

Gang

---

From: Maoke <[email-masked]>
Date: Thu, 6 Oct 2011 11:08:22 +0900

hi Gang,

trying to understand your point, may i follow your message inline? sorry if
my questions are trial/naive.

2011/10/6 GangChen <[email-masked]>

> translation(
> http://tools.ietf.org/html/draft-murakami-softwire-4v6-translation-00)
>
>
i couldn't understand why we "don't see such limitation in 4v6 translation".
4via6 translate the private ipv4 address with 4rd mapping rule while the
public ipv4 address with RFC6052 algorithm, right? can the both case work
fine if an ISP can only get a fairly long IPv6 prefix, like /40 or even
longer?

> First off, I'm not sure per-host traffic control is a common case for

i think it is common for, maybe, not any network operators but at least some
operators. especially for those running middle-to-small ISP services (like
my company), the capability of per-host traffic control is definitely
needed. a specific but not rare case is suppressing the pathologically
greedy download/upload behavior of bot-net boxes.

sorry but i may not yet understand the mapping algorithm. is the Rule IPv6
prefix definitely short enough to take all Max CE in the first 64 bits?
again, what if an ISP can only get a fairly long IPv6 prefix?

---

From: Congxiao Bao <[email-masked]>
Date: Thu, 6 Oct 2011 14:17:59 +0800

Hi, Gang, Maoke

2011/10/6 Maoke <[email-masked]>

> i couldn't understand why we "don't see such limitation in 4v6
> translation". 4via6 translate the private ipv4 address with 4rd mapping rule
> while the public ipv4 address with RFC6052 algorithm, right? can the both
> case work fine if an ISP can only get a fairly long IPv6 prefix, like /40 or
> even longer?
>

Yes, if ISP has /32 IPv6 address, then how to embed 32 bits IPv4 address and
PSID in the first 64 bits?

> i think it is common for, maybe, not any network operators but at least
> some operators. especially for those running middle-to-small ISP services
> (like my company), the capability of per-host traffic control is definitely

Agree.

> again, what if an ISP can only get a fairly long IPv6 prefix?
 For per-host traffic, the prefix length of ACL should be /128. In this
case, you have to specify the value of the suffix. So different ISPs in the
IPv6 data path can implement IPv6 ACL without additional knowledge.

Congxiao

---

From: Rémi Després <[email-masked]>
Date: Thu, 6 Oct 2011 10:37:38 +0800

Le 5 oct. 2011 à 22:45, Qiong a écrit :

> Hi, Remi,
> 
> Thanks for your effort. I think this is a big progress after the Interim meeting, and this unified address format is quite clear now.

Thanks.

> Here, I have two comments after a quick review. And I will get back to you if I have more comments later.
> 
> 1. With regard to destination address format, if I understand correctly, it only covers hub&spoke model with a default "BR subnet prefix". Are you intended to propose another format for mesh one ?

The proposed format does cover mesh domains - ref. draft-despres-softwire-4rd-addmapping-01 sections 5. and 9., in which "BR IPv6 address" should now be replaced by "BR IPv6 prefix" (a /64).
 
One or several BR IPv6 prefixes can be explicitly advertised to CEs as parts of Domain mapping rules, e.g. with DHCPv6. 

> Or just cite the "Source address format" as the destination address in MESH situation. I think it would be better to declare it separately for "H&S" and "MESH". This would be more clearer for readers to understand different situations.

When time comes to specify the unified format in a new draft, I agree that a clarification of how it applies to different topologies will be appropriate.
 
> 2. Still for the destination address format, I suggest to embed PSID as well in the lower 64 bits (as in the following).

The reported informal agreement we had in Beijing didn't explicitly cover destination addresses, and I just reported what we said, but this is AFAIK the implicit direction to go to.
Yet, there is a point to be taken into account:
- It concerns use cases where IPv6 prefixes are assigned without any relationship with IPv4 prefixes and where different sharing ratios are implicitly expressed by different IPv6 prefix lengths (they aren't the only use cases, but are the only ones where a flat IPv6 routing plan can be used with differentiated sharing ratios).
- For this, a BR or CE that transmits to a CE destination doesn't know the exact PSID length of this CE. It only knows the maximum possible length of this PSID, but this is enough for the right CE to be reached (ref draft-despres-softwire-4rd-addmapping-01 sec 7.)

Thus, for more generality, the format for a Destination CE would rather be:

<--------- 64 ------------>< 8 ><----   32 ----><--- 16 ----><8 >
+--------------------------+----+---------------+--------+---+---+
|     BR subnet prefix     | V  |  IPv4 address |Max PSID| 0 | L |
+--------------------------+----+---------------+--------+---+---+ 

If the PSID length is known, then the Max PSID is the exact PSID, but this isn't the only case.

> This would make it easier for in-the-middle systems(e.g. BNG) to do prefix mapping without packet decapsulation.

Exactly, that's the point of using IIDs to insert useful information.

> And this is quite similar to the source address format. What do you think of it?

Detailed answer above.

Kind regards,
RD

> Best wishes
> 
> Qiong
>   
> 
> On Tue, Oct 4, 2011 at 12:22 PM, Rémi Després <[email-masked]> wrote:
> Hi all,
> 
> 1.

---

From: Rémi Després <[email-masked]>
Date: Thu, 6 Oct 2011 10:51:36 +0800

> information if we only take traffic contronl on IPv6 data plane (as I

I agree that it is "not necessary" to exploit this field to filter IPv4 traffic.

Yet it MAY be used to facilitate configuration of traffic control parameters (IPv4 addresses are expressed in clear form instead of having to be derived with the help of mapping rules).
Besides, maintenance is facilitated if IPv4 addresses can be directly read in IPv6 addresses.

> the IID MAY not appeared in double translation cases.

The point is that:
- Copying the IPv4 address at a fixed place in IIDs has a negligible cost.
- Having a SINGLE standard format is cost saving. (I particular, if you don't plan to exploit it at first, you may be glad to have it in the future, at least for maintenance if for nothing else.)

Regards,
RD

---

From: Ole Troan <[email-masked]>
Date: Thu, 6 Oct 2011 06:47:48 -0400

Remi,

[...]

> <--------- 64 ------------><8 ><------ L >= 32 -------><48-L><8 >

putting the IPv4 address / port information at the end of the interface identifier will allow for > /64 support.
what's the L?

you suggest that the first subnet of an allocation should be used for this purpose.
the first subnet is convenient to use for e.g. manual addressing (since it allows the :: short hand).
I do wonder if this has to be provisioned. e.g. some deployments may use the first subnet for the link between
CE and PE. (i.e. a /56 - 1 using the PD exclude option is used).

> <--------- 64 ------------><8 ><-- L < 32 --><--- 48-L -----><8 >

or rather IEEE?
I am not convinced that "V" is needed.
you could even use the IANA OUI if pretty printing was required.

> A Destination address from a CE to the outside IPv4 Internet is:

this is a big change for encapsulation, where prior to this encapsulation means sending to a single destination.
if we also allow for a BR subnet prefix of /128 I'm OK with this (I think).

> Note that if double-translation CEs are notified to use U instead of V, the last octet becomes 0 per RFC  6052.

how would a CE know if it was single or double translating?

e.g we could do:

<--------- 64 ------------><--- 24 ------><----- 32 -------><--8 >
+-------------+--------+---+--------------------+------+-----+---+
| IPv6 prefix |CE index| S | 00-00-5E    |  IPv4 address  | PSID |
+-------------+--------+---+---+----------------+------+-----+---+

we also need to handle the case where IPv6 prefix + CE index > 64. I suggest we then just put as much as the interface identifier that will fit.

cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Thu, 6 Oct 2011 06:53:27 -0400

> i couldn't understand why we "don't see such limitation in 4v6 translation". 4via6 translate the private ipv4 address with 4rd mapping rule while the public ipv4 address with RFC6052 algorithm, right? can the both case work fine if an ISP can only get a fairly long IPv6 prefix, like /40 or even longer? 
>  
> Yes, if ISP has /32 IPv6 address, then how to embed 32 bits IPv4 address and PSID in the first 64 bits?

only part of the IPv4 address would be embedded into the first 64 bits (not that I think that boundary should be "hard").
e.g. if the SP has the prefix 10/8. the user the address 10.1.2.3. then only "1.2.3" would be embedded in the address.
just like what's done for 6rd.

cheers,
Ole

---

From: Congxiao Bao <[email-masked]>
Date: Thu, 6 Oct 2011 21:57:49 +0800

2011/10/6 Ole Troan <[email-masked]>

> only part of the IPv4 address would be embedded into the first 64 bits (not
> that I think that boundary should be "hard").
> e.g. if the SP has the prefix 10/8. the user the address 10.1.2.3. then
> only "1.2.3" would be embedded in the address.

Thanks, Ole. That’s the point! In this case , you can only have part of the
IPv4 address embedded in the first 64 bits. This embedding does work for
encapsulation or tunneling, but can NOT work for stateless double
translation, which requires the whole IPv4 address+PSID embeded for any IPv6
prefix length.

Best,

Congxiao

---

From: Ole Troan <[email-masked]>
Date: Thu, 6 Oct 2011 10:03:18 -0400

> Thanks, Ole. That’s the point! In this case , you can only have part of the IPv4 address embedded in the first 64 bits. This embedding does work for encapsulation or tunneling, but can NOT work for stateless double translation, which requires the whole IPv4 address+PSID embeded for any IPv6 prefix length.

right, for the outside domain traffic.
putting the state into the IPv6 destination address doesn't affect routing.
so this works fine with the case where you give a user a /56, where you have to have efficient encoding. for the external to the domain traffic you need to encode the full IPv4 address.

cheers,
Ole

---

From: Maoke <[email-masked]>
Date: Thu, 6 Oct 2011 23:14:55 +0900

> > only part of the IPv4 address would be embedded into the first 64 bits
> (not that I think that boundary should be "hard").
> > Thanks, Ole. That’s the point! In this case , you can only have part of
> the IPv4 address embedded in the first 64 bits. This embedding does work for
> so this works fine with the case where you give a user a /56, where you
> have to have efficient encoding. for the external to the domain traffic you
> need to encode the full IPv4 address.
>
> cheers,
> Ole

thanks a lot, Ole and Prof. Bao, for the discussion. then i got to fairly
understand the situation. :)

cheers,
maoke

---

From: Rémi Després <[email-masked]>
Date: Thu, 6 Oct 2011 18:06:59 +0800

> putting the IPv4 address / port information at the end of the interface identifier will allow for > /64 support.

Could you explain more the requirement you have in mind?  

> what's the L?

On the picture, L is 32 bits + Length(PSID).
Don't see what you found unclear. 

> you suggest that the first subnet of an allocation should be used for this purpose.

Did I do this?
Please explain because that's not, IMHO,  something to be done.

> CE and PE. (i.e. a /56 - 1 using the PD exclude option is used).

See just above.

>> Note that, if and when a consensus is reached in Softwire, an extension of RFC 4291 will have to be submitted to 6MAN. 

IMHO, IEEE has nothing to do with a marker that is purposely an escape mechanism from the modified EUI-64 format of RFC 4291.

> I am not convinced that "V" is needed.

The point is more, IMHO, whether you have an objection to it (and in this case which one).
Reason is that we are working for a consensus, and several are satisfied with the explanation that there are use cases where it is useful, and none where it is harmful.

> you could even use the IANA OUI if pretty printing was required.

The point is that it takes 32 bits which is too much to have IPv4 address + PSID in the IID.

> this is a big change for encapsulation, where prior to this encapsulation means sending to a single destination.

Copying an available IPv4 address at a fixed place isn't IMHO a "big change".

> if we also allow for a BR subnet prefix of /128 I'm OK with this (I think).

I don't understand what you mean by "Subnet prefix of /128".

> how would a CE know if it was single or double translating?

Presumably with a usual method, e.g. DHCPv6.
Anything problematic with that?

> we also need to handle the case where IPv6 prefix + CE index > 64.

Please explain more your understanding of this requirement.
(I personally believe we should avoid that.)

> I suggest we then just put as much as the interface identifier that will fit.

May I suggest that, to be more constructive, you could first express your objections to the proposed unified mapping, rather than making a number of new proposals whose justifications are sometimes hard to understand, 

Cheers,
RD

---

From: Ole Troan <[email-masked]>
Date: Thu, 6 Oct 2011 12:13:06 -0400

Remi,

> May I suggest that, to be more constructive, you could first express your objections to the proposed unified mapping, rather than making a number of new proposals whose justifications are sometimes…

I'd rather that we agree on the requirements.
my questions were against what requirements you based parts of your proposal on. are these new/different requirements from those I showed on the slide in Beijing?

cheers,
Ole

---

From: Rémi Després <[email-masked]>
Date: Thu, 6 Oct 2011 19:16:56 +0800

> my questions were against what requirements you based parts of your proposal on. are these new/different requirements from those I showed on the slide in Beijing?

Please send a copy of the slide you are referring to.
Thanks.
RD

---

From: Ole Troan <[email-masked]>
Date: Thu, 6 Oct 2011 16:59:57 -0400

Remi,

> Please send a copy of the slide you are referring to.

certainly.

cheers,
Ole

---

From: GangChen <[email-masked]>
Date: Sat, 8 Oct 2011 00:18:28 +0800

Hello Congxiao, Maoke,

> PSID in the first 64 bits?
4v6 translation doesn’t need to embed whole 32 bits IPv4 address
according to the algorithm. Please take look EA-bits usage in
http://tools.ietf.org/html/draft-murakami-softwire-4rd-01 for more
details

>> prefix definitely short enough to take all Max CE in the first 64 bits?

Yes, in padding case.

>> again, what if an ISP can only get a fairly long IPv6 prefix?

Can I interpret your question like how can we configure mapping
parameter if ISP only gets a fairly long IPv6 prefix? Yes. I mean that
could be possible for some ISP. However, I find that is somewhat
contradictory with requirement of prefix delegation deployment. (Note:
there are also some statements for this requirement in
draft-boucadair-softwire-stateless-requirements-00 REQ#1, REQ#4). At
least, I see all current practices are trying to encoding the
information in first 64 bits (e.g.
draft-despres-softwire-4rd-addmapping-01
draft-boucadair-behave-ipv6-portrange-04
draft-murakami-softwire-4rd-00
draft-murakami-softwire-4v6-translation-00
draft-xli-behave-divi-pd-01
draft-chen-softwire-4v6-pd-00)

> IPv6 data path can implement IPv6 ACL without additional knowledge.

Again. If there is a way to identify each user in first 64 bits, why not use.

Many thanks

Gang

---

From: GangChen <[email-masked]>
Date: Sat, 8 Oct 2011 11:26:04 +0800

Hello Remi,

2011/10/6, Rémi Després <[email-masked]>:
> Yet it MAY be used to facilitate configuration of traffic control parameters
> (IPv4 addresses are expressed in clear form instead of having to be derived
> with the help of mapping rules).

May I clarify whether such traffic control parameters are for IPv4 or
IPv6 data plane?

Many thanks

Gang

---

From: Maoke <[email-masked]>
Date: Sat, 8 Oct 2011 19:11:46 +0900

hi Gang,

2011/10/8 GangChen <[email-masked]>

> http://tools.ietf.org/html/draft-murakami-softwire-4rd-01 for more
i suppose Ole and Congxiao have clarified this point, right? for the double
translation, full ipv4 address is needed.

> >> prefix definitely short enough to take all Max CE in the first 64 bits?
what do you mean with the "yes"? do you mean having a short-enough Rule-IPv6
is a prerequisite for deploying 4rd-pd?

for example, a small ISP has its Rule IPv4 prefix such as 10/8, while its
total IPv6 block is a /48 or a /56 prefix only. the ISP is deploying
stateless transition, possibly 4rd-pd. is such an ISP surely able to pad
necessary part of IPv4 address in the first 64 bits?

> could be possible for some ISP.

it *could* be *possible* for *some* ISP but not for any ISP, right?

> However, I find that is somewhat
i don't think all current practices are "trying to encode the information in
the first 64bits". to my humble understanding, at least divi-pd encodes the
IPv4 full address information, which identifies a specific user, not in the
first 64 bits.

> Again. If there is a way to identify each user in first 64 bits, why not
in your proposal draft-chen-softwire-4v6-pd-00, you have

  Delegated IPv6 prefix = IPv6 prefix + Add set + Port set

where your Add-set is (32 - IPv4_pref_len) long, right? if the IPv4_pref_len
= 8 while the IPv6_prefix_len = 48, can your first 64bits identify a user?

thanks and regards,
maoke

---

From: Jacni Qin <[email-masked]>
Date: Sat, 08 Oct 2011 22:46:44 +0800

hi,

Inline please,

On 10/5/2011 5:42 PM, Congxiao Bao wrote:
> Hi,
>
> 2011/10/5 Rémi Després <[email-masked] 
> <mailto:[email-masked]>>
>
>     ..
>     >
Sorry, I don't follow your point here. If there is only one host behind 
the CE, why do we enable both encapsulation and translation modes? Or 
you're talking about the case where a prefix is assigned? Even in this 
case, do we really want parts of the hosts to live on translation, while 
the others live on encapsulation?

>     The CE Pv6 prefix included in the /64 Subnet prefix isn't self
>     delimited, so that the length of the CE index can't be determined
>     in this part of the address.
> Besides, if a medium or large size ISP can’t get short enough IPv6 
> prefix (ex. /24), the first 64 bits can not contain the whole IPv4 32 
> bits, which cannot make the double translation successful.
>
>
I guess the figures were not intent to show in detail how could the IPv4 
space be derived, where maybe not the whole 32 bits are needed. Anyway, 
it's true that the original IPv4 address has to be embedded in the 
translated-address if the translation approach is employed.

>     Besides, having the IPv4 address (or prefix) in clear form, and
>     with an explicit sharing ratio, facilitates maintenance at
>     essentially no cost.
>
If the ACL control is based on the first 64 bits, then that control may 
apply to encapsulation as well.

Cheers,
Jacni

>     A point is that, although some realistic deployments may ignore
>     what is made available in IIDs (at least at the beginning), some
>     others would take advantage of it.
>     A standard with a straightforward and unified format is AFAIK
>     better than several variants, at least for documentation,
>     training, maintenance etc.
>
>     Note also that even with a single standard, it remains possible to
>     add optional variants if found useful for some deployments.
>
> The ISP is not able to achieve per-host traffic control without a 
> standard defining last 64 bits. If the ISP does, why not use IPv4+psid 
> in suffix naturally instead of other new bits definition?
>
> Best,
>
> Congxiao
>
>
>     Hope it clarifies.
>
>
>     Regards,
>     RD
>
>
>     >
>     > Many thanks
>     >
>     >
>     >
>     > Gang
>     >
>     > 2011/10/4, Rémi Després <[email-masked]
>     <mailto:[email-masked]>>:
>     >> Hi all,
>     >>
>     >> 1.
>     >> V is the mark that characterizes IPv6 packets that are in
>     reality IPv4
>     >> packets.
>     >> Its value differs from any permitted value of this octet in
>     IPv6 IIDs  (ref
>     >> RFC 4291).
>     >>
>     >> (With other values of this octet, other IID formats can be
>     defined in case
>     >> Note that if double-translation CEs are notified to use U
>     instead of V, the
>     >> [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Jacni Qin <[email-masked]>
Date: Sat, 08 Oct 2011 23:01:17 +0800

hi,

Inline please,

On 10/6/2011 10:37 AM, Rémi Després wrote:
> ...
>
>> 2. Still for the destination address format, I suggest to embed PSID 
>> as well in the lower 64 bits (as in the following).
>
> The reported informal agreement we had in Beijing didn't explicitly 
> cover destination addresses, and I just reported what we said, but 
> this is AFAIK the implicit direction to go to.
> - It concerns use cases where IPv6 prefixes are assigned without any 
> relationship with IPv4 prefixes and where different sharing ratios are 
> implicitly expressed by different IPv6 prefix lengths (they aren't the 
> only use cases, but are the only ones where a flat IPv6 routing plan 
> can be used with differentiated sharing ratios).
> - For this, a BR or CE that transmits to a CE destination doesn't know 
> the exact PSID length of this CE. It only knows the maximum possible 
> length of this PSID, but this is enough for the right CE to be reached 
> (ref draft-despres-softwire-4rd-addmapping-01 sec 7.)
>
I understand the "Max" PSID, based on which there will be no problem 
being routed to the destination. While I'm rethinking of it from the 
implementation perspective, the IID part the IPv6 address destined to a 
given CE should be a fixed value (the same as the IID of the "4rd 
interface" for example). Then the variable "max" PSID derived from dst. 
ports may get a problem.

Cheers,
Jacni

---

From: Jacni Qin <[email-masked]>
Date: Sat, 08 Oct 2011 23:09:07 +0800

hi,

Inline please,

> so this works fine with the case where you give a user a /56, where you have to have efficient encoding. for the external to the domain traffic you need to encode the full IPv4 address.
The phase to get v4 space from delegated prefix is different from 
forming IPv6 address for sending traffic.

Cheers,
Jacni

---

From: GangChen <[email-masked]>
Date: Sun, 9 Oct 2011 11:14:24 +0800

Hello Maoke,

> translation, full ipv4 address is needed.

As Ole said, "for the outside domain traffic" (Actually, I never argue
that point for that case)
Thereby, it's worth to be clarified whether need encoding whole IPv4
address, as the below table

+----------+-----------------+--------------------+
|          |source address   | destination address|
+----------+-----------------+--------------------+
|  CE-CE   |      N/A        |        N/A         |
+----------+-----------------+--------------------+
|  CE-BR   |      N/A        |        Yes         |
+----------+-----------------+--------------------+

> necessary part of IPv4 address in the first 64 bits?

I guess I have already put some comments on that. Please see below.

> IPv4 full address information, which identifies a specific user, not in the

Thanks for the clarification. That is why you propose to insert full
IPv4 address?

---

From: Qiong <[email-masked]>
Date: Sun, 9 Oct 2011 11:57:35 +0800

Hi, Gang,

On Sun, Oct 9, 2011 at 11:14 AM, GangChen <[email-masked]> wrote:

> In case you need to embed the full IPv4 address for destination address in
CE-BR, why not define a unified address format for CE-CE model. I think it
would be easier to implement and easier to achieve further traffic
identification in the same way.

Best wishes

Qiong

---

From: Maoke <[email-masked]>
Date: Sun, 9 Oct 2011 13:28:13 +0900

hi Gang,

thanks for the reply.

2011/10/9 GangChen <[email-masked]>

> I guess I have already put some comments on that. Please see below.
do you mean you *require" every ISP surely having IPv6 prefix shorter than,
e.g., /32? may i beg you answer this question without equivocation. :)
thanks!

> Thanks for the clarification. That is why you propose to insert full
well, i didn't propose anything new. some cases need full IPv4 addresses
while these cases are included in our discussion on the unified address
mapping.

> > = 8 while the IPv6_prefix_len = 48, can your first 64bits identify a

on the other hand, may you also answer this question?

thanks and regards,
maoke

---

From: Maoke <[email-masked]>
Date: Sun, 9 Oct 2011 13:31:06 +0900

hi Qiong,

2011/10/9 Qiong <[email-masked]>

> identification in the same way.
agree.

best,
maoke

---

From: Zhen Cao <[email-masked]>
Date: Sun, 9 Oct 2011 19:25:13 +0800

> address, as the below table

I like this matrix, very clear for discussion and should serve as the
basis for any arguments regarding the reasons for our choice.

-- 
Best regards,
Zhen

---

From: Zhen Cao <[email-masked]>
Date: Sun, 9 Oct 2011 19:30:08 +0800

> identification in the same way.

I think this is a different story. For the CE-BR communication, since
the destination node is not within the domain, we can't and do not
need to use the same mapping algorithm as well as the address format
for the destination address part.  The mapping only applies to the
source address part. That's what's discussed during the interim.

-- 
Best regards,
Zhen

---

From: GangChen <[email-masked]>
Date: Sun, 9 Oct 2011 19:30:45 +0800

Hello Maoke,

Please my reply inline.

2011/10/9, Maoke <[email-masked]>:
> e.g., /32?

I'm not sure what formula you have to deduce this *requirement*.
Different sharing ratios should implicitly be expressed by different
IPv6 prefix lengths when an operator would deploy PD. At this point,
you can't help even you encode whole IPv4 address in suffix. As for
the question you raised, I think that are operational issues more than
technical issues. I take your example as explanation for your better
understanding.

A small ISP has its Rule IPv4 prefix such as 10/8, while its total
IPv6 block has fairly long prefix like /48 or a /56.

Then an operator could strategically pre-config a relatively small
IPv4 subnet to 4v6 domain as rule IPv4 prefix, like 10/24. Then you
could get more space in IPv6 prefix to put PSID information. See that
is quite flexible if you do have a good operational planning.

>may i beg you answer this question without equivocation. :)
> thanks!

Sorry for the confusion. I hope above explanation could help.

>> > i don't think all current practices are "trying to encode the
>> > information
>> in

I only see your one case here.

> on the other hand, may you also answer this question?

See above example. BTW, I have never said the IPv6 prefix in
draft-chen-softwire-4v6-pd-00 could identify each user.
What I said in a previous email is MAX PSID in addrmapping-01 could
help to identify a specific user. Please don't get me wrong.

Many thanks

Gang

---

From: liu dapeng <[email-masked]>
Date: Mon, 10 Oct 2011 01:09:25 +0800

Agree.

Regards,
Dapeng Liu

-- 

------
Best Regards,
Dapeng Liu

---

From: Jacni Qin <[email-masked]>
Date: Mon, 10 Oct 2011 12:47:24 +0800

hi,

One comment on the example you proposed, please see below,

> is quite flexible if you do have a good operational planning.
I get it, but let me try in another way.
The IPv6 addressing must not be affected, that's one of the basic 
objectives of MAP we'll agree on, right?

So, firstly the IPv6 address planning should be done natively according 
to the service requirements, the expected scale of subscribers, and the 
address space assigned respectively.
For example, if you plan to assign a /60 to each subscriber in a given 
domain with 1M subscribers totally, an IPv6 prefix of "/40" is required 
(probably shorter given the efficiency loss of hierarchical aggregation).
Then, this becomes the assumption (or restriction) on which we've got 20 
bits space to play with our art.

The next step is to decide the sharing ratio, say, 2k ports per 
subscriber, the PSID will be of 5 bits. Here the tradeoff is to use how 
many bits borrowed from ports or from the first 32 bits.
Then in this case, an IPv4 prefix of "/17" is required to accommodate 
the 1M subscribers (through "15+5").
If we're lucky to get a block of "/17", one piece of MAP rule is enough. 
Otherwise, we'll have to face another tradeoff, smaller number of rules 
or smaller number of fragmented blocks used.

ISPs' cases are quite different, while the philosophy of address 
planning is not, and should be kept in mind when we design the MAP.

Cheers,
Jacni

---

From: Rémi Després <[email-masked]>
Date: Mon, 10 Oct 2011 09:23:13 +0200

> May I clarify whether such traffic control parameters are for IPv4 or

As I understand it, the objective is to use existing traffic-control tools of IPv6 for both IPv6 AND IPv4.
This seems to me a valuable feature. 

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Mon, 10 Oct 2011 09:26:23 +0200

Le 8 oct. 2011 à 17:01, Jacni Qin a écrit :

> I understand the "Max" PSID, based on which there will be no problem being routed to the destination. While I'm rethinking of it from the implementation perspective, the IID part the IPv6 address destined     to a given CE should be a fixed value (the same as the IID of the "4rd interface" for example).

The 4rd function examines ALL packets that reach the CE.
It processes all those that have V in their destination addresses, and only those.

The reason why 4rd packets reach the CE is NOT that their destinations are the IPv6 address that the CE has on its link to the ISP. 
It is that their destinations start with the CE delegated prefix. The routing information base of the ISP edge router is such that, for such destinations, the next hop is the CE. 

> Then the variable "max" PSID derived from dst. ports may get a problem.

Not AFAIK because of the above.

Hope it clarifies.
Cheers,
RD

---

From: Jacni Qin <[email-masked]>
Date: Mon, 10 Oct 2011 15:47:56 +0800

hi Remi,

> It processes all those that have V in their destination addresses, and 
This is a big change to the current forwarding behavior of CPE devices, 
doable, but quite different from, for example, some 
encapsulation/decapsulation implementations.

Cheers,
Jacni

---

From: Rémi Després <[email-masked]>
Date: Mon, 10 Oct 2011 09:58:22 +0200

Le 10 oct. 2011 à 09:47, Jacni Qin a écrit :

> This is a big change to the current forwarding behavior of CPE devices, doable, but quite different from, for example, some encapsulation/decapsulation implementations.

That's new, yes, but in my understanding not so complex once you know what you want to do.
This is what permits to use IPv6 delegated prefixes that have no relationship with IPv4, and still be able to assign differentiated sharing ratios to CEs.

I believe this is a valuable feature of the standard to be specified.
Yet, it will be up to the WG, influenced by the design team, to decide to keep this feature or not.
  
Cheers,
RD

---

From: Maoke <[email-masked]>
Date: Mon, 10 Oct 2011 17:40:04 +0900

hi Jacni,

thanks for the discussion from the view of address planning. it is clear.
i just would like to add an overview comment on the "philosophy".

to my understanding, the prefix length to a customer depends upon,
essentially, how many end-system identifiers are needed, according to what
we estimate, within the scope of the customer network. in the age of IPv4,
the estimation is typically expressed with a definite prefix length because
we hardly have a shorter one than what we really need. in the age of IPv6,
however, if the prefix length for a customer network in address planning is
not a fixed value but a range with relaxation, the art of address planning
may also change. (e.g., the block assigned to a subscriber is at most
/60 supporting up to 1M subscribers in total, and at least /72 in oder to
support up to 2^56 end-system identifiers within each CE-delegated network).
with this in mind, ISP may have larger room to pick up techniques and
deployment tactics possibly without doing less-necessary tradeoffs.

the same philosophy doesn't imply a unique art of action. MHO. sorry but out
of the scope of this group.

thanks a lot,
maoke

2011/10/10 Jacni Qin <[email-masked]>

> So, firstly the IPv6 address planning should be done natively according to
> the service requirements, the expected scale of subscribers, and the address
> space assigned respectively.
> The next step is to decide the sharing ratio, say, 2k ports per subscriber,
> the PSID will be of 5 bits. Here the tradeoff is to use how many bits
> borrowed from ports or from the first 32 bits.
> Then in this case, an IPv4 prefix of "/17" is required to accommodate the
> 1M subscribers (through "15+5").
> Otherwise, we'll have to face another tradeoff, smaller number of rules or
> smaller number of fragmented blocks used.
>
>
ISPs' cases are quite different, while the philosophy of address planning is
> not, and should be kept in mind when we design the MAP.
>
>

Cheers,
Jacni

---

From: Ole Troan <[email-masked]>
Date: Mon, 10 Oct 2011 10:58:25 +0200

> This is a big change to the current forwarding behavior of CPE devices, doable, but quite different from, for example, some encapsulation/decapsulation implementations.

+1.
doable in theory, but I share your concerns.

cheers,
Ole

---

From: Leaf yeh <[email-masked]>
Date: Mon, 10 Oct 2011 11:34:59 +0000

>> <--------- 64 ------------><8 ><------ L >= 32 -------><48-L><8 >
Ole - > putting the IPv4 address / port information at the end of the interface identifier will allow for > /64 support. > what's the L?
Remi - Don't see what you found unclear.

Question: Supposed the question is on the last field, named 'L', in the new address format.

Ole - this is a big change for encapsulation, where prior to this encapsulation means sending to a single destination.
Remi - Copying an available IPv4 address at a fixed place isn't IMHO a "big change".

Concern: Supposed the replacement of the 1st 64bits of the BR address with a subnet prefix is not for the tunnel case if the field of IPv4 address can be variable, right?

In fact, I doubts we could have the same address mapping for both tunnel and translation. Supposed the address of tunnel end-points is preferred to be fixed, but the address for the translation could be variable.

Best Regards,
Leaf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rémi Després
Sent: Thursday, October 06, 2011 6:07 PM
To: Ole Troan
Cc: Softwires-wg
Subject: Re: [Softwires] Proposed Unified Address Mapping for encapsulation and double-translation

Did I do this?

See just above.

Cheers,
RD

---

From: Jacni Qin <[email-masked]>
Date: Mon, 10 Oct 2011 19:54:36 +0800

hi,

On 10/10/2011 4:40 PM, Maoke wrote:
> hi Jacni,
> thanks for the discussion from the view of address planning. it is 
> clear. i just would like to add an overview comment on the "philosophy".
> essentially, how many end-system identifiers are needed, according 
> to what we estimate, within the scope of the customer network. in the 
> age of IPv4, the estimation is typically expressed with a definite 
> prefix length because we hardly have a shorter one than what we really 
> need. in the age of IPv6, however, if the prefix length for a customer 
> network in address planning is not a fixed value but a range with 
> relaxation, the art of address planning may also change. (e.g., 
> the block assigned to a subscriber is at most /60 supporting up 
> to 1M subscribers in total, and at least /72 in oder to support up 
> to 2^56 end-system identifiers within each CE-delegated network). with 
> this in mind, ISP may have larger room to pick up techniques and 
Thanks for your comments, I was only guessing based on experiences from 
IPv4. And yes, as you mentioned, something will change in IPv6.
While I think in practice, from ISP's perspective, probably there won't 
be that much flexibility, for example, there can't be too many SLAs.
Anyway, we can only know that after IPv6 comes true. ;-)

Cheers,
Jacni

> the same philosophy doesn't imply a unique art of action. MHO. sorry 
> but out of the scope of this group.
> thanks a lot,
> maoke
> 2011/10/10 Jacni Qin <[email-masked] <mailto:[email-masked]>>
>
>     hi,
>
>     So, firstly the IPv6 address planning should be done natively
>     according to the service requirements, the expected scale of
>     subscribers, and the address space assigned respectively.
>     For example, if you plan to assign a /60 to each subscriber in a
>     given domain with 1M subscribers totally, an IPv6 prefix of "/40"
>     is required (probably shorter given the efficiency loss of
>     hierarchical aggregation).
>     Then, this becomes the assumption (or restriction) on which we've
>     got 20 bits space to play with our art.
>
>     subscriber, the PSID will be of 5 bits. Here the tradeoff is to
>     use how many bits borrowed from ports or from the first 32 bits.
>     Then in this case, an IPv4 prefix of "/17" is required to
>     accommodate the 1M subscribers (through "15+5").
>     If we're lucky to get a block of "/17", one piece of MAP rule is
>     enough. Otherwise, we'll have to face another tradeoff, smaller
>     number of rules or smaller number of fragmented blocks used.
>

---

From: Qiong <[email-masked]>
Date: Mon, 10 Oct 2011 23:12:41 +0800

Hi, Remi and Jacni,

> It processes all those that have V in their destination addresses, and only

Qiong: I think it might be better achieved via routing lookup for prefix+V
bits (e.g. /80 ), rather than extracting V bits before traditional routing.

>
> The reason why 4rd packets reach the CE is NOT that their destinations are
> the IPv6 address that the CE has on its link to the ISP.
> It is that their destinations start with the CE delegated prefix. The
> routing information base of the ISP edge router is such that, for such
> destinations, the next hop is the CE.
>
>
>  Qiong: I think the "max" PSID design might have a problem in virtual
interface implementation. When implementing an virtual
encapsulation/translation interface, the packets can reach the virtual
interface from a downstream physical interface via traditional routing. For
example, identifying a specific address or /80 prefix to the destinated
virtual interface. However, when the "max" PSID is not stable and the length
of "Rule IPv6 prefix+ Max PSID" exceeds 64 bit long, how to construct this
kind of internal routing table ? I think it would be too many routing
entries here.

Best wishes

Qiong

---

From: Rémi Després <[email-masked]>
Date: Mon, 10 Oct 2011 17:17:44 +0200

Le 10 oct. 2011 à 17:12, Qiong a écrit :

> On Mon, Oct 10, 2011 at 3:26 PM, Rémi Després <[email-masked]> wrote:
> 
> Qiong: I think it might be better achieved via routing lookup for prefix+V bits (e.g. /80 ), rather than extracting V bits before traditional routing.
>  
> 

>  Qiong: I think the "max" PSID design might have a problem in virtual interface implementation. When implementing an virtual encapsulation/translation interface, the packets can reach the virtual interface from a downstream physical interface via traditional routing.

> For example, identifying a specific address or /80 prefix to the destinated virtual interface. However, when the "max" PSID is not stable and the length of "Rule IPv6 prefix+ Max PSID" exceeds 64 bit long, how to construct this kind of internal routing table ? I think it would be too many routing entries here.

Routing being only concerned with /64s, and information in IIDs being used only by 4rd functions themselves, or for O&M, I don't see the problem.

Regards,
RD

---

From: Qiong <[email-masked]>
Date: Mon, 10 Oct 2011 23:33:16 +0800

Hi, Qiong,

Please see inline.

> interface from a downstream physical interface via traditional routing.
>
>
> For example, identifying a specific address or /80 prefix to the destinated
> Routing being only concerned with /64s, and information in IIDs being used
> only by 4rd functions themselves, or for O&M, I don't see the problem.
>
> Qiong: My concern is specific for virtual interface implementation. If you
implement a virtual interface(as most existing encapsulation approaches have
adopted in CPE ), you still need to do routing within CE (from physical
interface to virtual interface). In traditional encapsulation
implementation, a specific routing entry can be assigned to help forward the
traffic with a tunnel endpoint address. And all the following decapsulation
things can be done in this virtual interface. I think this kind of
implementation can be applied to translation as well, to make use of
traditional routing and implementation translation functionality only on the
virtual interface. And since the first 64 bits will be same for both native
traffic and translated traffic, the lower bits would be needed for internal
routing. That's why I think unstable "max" PSID would make it difficult to
construct internal routing table (not routing procedure from ISP to CE). But
anyway, it is only restricted to this kind of implementation (determine the
translated traffic by routing rather than bit extracting).

Hope it is clear now.

Thanks

Qiong

---

From: Rémi Després <[email-masked]>
Date: Mon, 10 Oct 2011 17:44:02 +0200

Le 10 oct. 2011 à 17:33, Qiong a écrit :

> Qiong: My concern is specific for virtual interface implementation. If you implement a virtual interface(as most existing encapsulation approaches have adopted in CPE ), you still need to do routing within CE (from physical interface to virtual interface). In traditional encapsulation implementation, a specific routing entry can be assigned to help forward the traffic with a tunnel endpoint address. And all the following decapsulation things can be done in this virtual interface. I think this kind of implementation can be applied to translation as well, to make use of traditional routing and implementation translation functionality only on the virtual interface. And since the first 64 bits will be same for both native traffic and translated traffic, the lower bits would be needed for internal routing. That's why I think unstable "max" PSID would make it difficult to construct internal routing table (not routing procedure from ISP to CE). But anyway, it is only restricted to this kind of implementation (determine the translated traffic by routing rather than bit extracting). 
> 
> Hope it is clear now.

This is an implementation issue about which others may be better placed than me to give a quick answer.

I only know it is feasible by putting some simple code at some appropriate place(s).
Sorry I can't tell more without some consultancy based on details of your implementation.

Regards,
RD

---

From: Jacni Qin <[email-masked]>
Date: Tue, 11 Oct 2011 15:36:59 +0800

hi,

On 10/10/2011 11:33 PM, Qiong wrote:
> Hi, Qiong,
>
> Please see inline.
>
>>     On Mon, Oct 10, 2011 at 3:26 PM, Rémi Després
>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>
>>     Qiong: I think it might be better achieved via routing lookup for
>>     prefix+V bits (e.g. /80 ), rather than extracting V bits before
>>     traditional routing.
>>
>>
>>         The reason why 4rd packets reach the CE is NOT that their
>>         destinations are the IPv6 address that the CE has on its link
>>         to the ISP.
>>         It is that their destinations start with the CE delegated
>>         prefix. The routing information base of the ISP edge router
>>         is such that, for such destinations, the next hop is the CE.
>>
>>
>>      Qiong: I think the "max" PSID design might have a problem in
>>     virtual interface implementation. When implementing an virtual
>>     encapsulation/translation interface, the packets can reach the
>>     virtual interface from a downstream physical interface via
>>     traditional routing.
>
>>     For example, identifying a specific address or /80 prefix to the
>>     destinated virtual interface. However, when the "max" PSID is not
>>     stable and the length of "Rule IPv6 prefix+ Max PSID" exceeds 64
>>     bit long, how to construct this kind of internal routing table ?
>>     I think it would be too many routing entries here.
>
>     Routing being only concerned with /64s, and information in IIDs
>     being used only by 4rd functions themselves, or for O&M, I don't
>     see the problem.
>
> Qiong: My concern is specific for virtual interface implementation. If 
> you implement a virtual interface(as most existing encapsulation 
> approaches have adopted in CPE ), you still need to do routing within 
> CE (from physical interface to virtual interface). In traditional 
> encapsulation implementation, a specific routing entry can be assigned 
> to help forward the traffic with a tunnel endpoint address. And all 
> the following decapsulation things can be done in this virtual 
> interface. I think this kind of implementation can be applied to 
> translation as well, to make use of traditional routing and 
> implementation translation functionality only on the virtual interface.
I doubt whether the two can share the same interface by just switching 
between encapsulation/translation modes, maybe a separated one is needed 
for translation since the implementation is different.

Cheers,
Jacni

> And since the first 64 bits will be same for both native traffic and 
> translated traffic, the lower bits would be needed for internal 
> routing. That's why I think unstable "max" PSID would make it 
> difficult to construct internal routing table (not routing procedure 
> from ISP to CE). But anyway, it is only restricted to this kind of 
> implementation (determine the translated traffic by routing rather 
> than bit extracting).
>
> Hope it is clear now.
>
> Thanks
>
> Qiong
>

---

From: Qiong <[email-masked]>
Date: Tue, 11 Oct 2011 16:24:03 +0800

Hi, Jacni

> you implement a virtual interface(as most existing encapsulation approaches
> have adopted in CPE ), you still need to do routing within CE (from physical
> virtual interface.
> between encapsulation/translation modes, maybe a separated one is needed for
> translation since the implementation is different.
>
>
> Agree that separated interfaces might be needed for different
implementation. As long as the traffic can still be differentiated via
routing, different functionality can be applied to different interfaces. So
I think we may need to focus on defining a flexible prefix for routing,
rather than bit extracting. But anyway, I do not think it would be a common
case that translation and encapsulation will be running simultaneous.

Best wishes

Qiong

> translated traffic, the lower bits would be needed for internal routing.
> That's why I think unstable "max" PSID would make it difficult to construct
> internal routing table (not routing procedure from ISP to CE). But anyway,
> it is only restricted to this kind of implementation (determine the

---

From: Satoru Matsushima <[email-masked]>
Date: Tue, 11 Oct 2011 17:30:25 +0900

Leaf, thanks for the summary.

> Question: Supposed the question is on the last field, named 'L', in the new address format.

Since Remi's draft doesn't specify 'CE IPv6 prefix length', IPv6 prefix can't be self delimiting to extract IPv4 address and port-set ID in the case of double translation. That's my understanding. Is that correct?
As '4rd-a', and 4via6(draft-murakami-softwire-4v6-translation), the 'L' bits are not necessary because 'CE IPv6 prefix length' is defined through a domain, instead of 'L'.

> Concern: Supposed the replacement of the 1st 64bits of the BR address with a subnet prefix is not for the tunnel case if the field of IPv4 address can be variable, right?

I think that it could be a case where the BR address with a subnet prefix for the tunnel case. My concern rather than the BR address is that a CE should pick packets up which have 'V' in IID, even destined prefixes are delegated to nodes which are behind of the CE.

> In fact, I doubts we could have the same address mapping for both tunnel and translation. Supposed the address of tunnel end-points is preferred to be fixed, but the address for the translation cou…

I think we could have it.

cheers,
--satoru

---

From: Satoru Matsushima <[email-masked]>
Date: Tue, 11 Oct 2011 17:40:29 +0900

+1.

cheers,
--satoru

---

From: Rémi Després <[email-masked]>
Date: Tue, 11 Oct 2011 10:42:23 +0200

> Since Remi's draft doesn't specify 'CE IPv6 prefix length', IPv6 prefix can't be self delimiting to extract IPv4 address and port-set ID in the case of double translation. That's my understanding.…

In my understanding, yes.

Now, putting the "CE IPv6 prefix length" back as a rule parameter shouldn't be a problem if the idea of linking IPv4 and IPv6 sizes of address spaces is abandoned (a choice that, I have to agree, simplifies the design).

Cheers,
RD

---

From: Satoru Matsushima <[email-masked]>
Date: Tue, 11 Oct 2011 18:47:58 +0900

> Now, putting the "CE IPv6 prefix length" back as a rule parameter shouldn't be a problem if the idea of linking IPv4 and IPv6 sizes of address spaces is abandoned (a choice that, I have to agree, s…

I think that it should be exclusive in a domain but it could be coexist in the map specification.

cheers,
--satoru

---

From: Leaf yeh <[email-masked]>
Date: Tue, 11 Oct 2011 11:00:41 +0000

> Remi - >> A Destination address from a CE to the outside IPv4 Internet is:
Leaf -> In fact, I doubts we could have the same address mapping for both tunnel and translation. Supposed the address of tunnel end-points is preferred to be fixed, but the address for the translation could be variable.
Satoru -> I think we could have it.

What is the definition of the IPv4 address in the above format? Is it the destination IPv4 address of any hosts outside 4rd IPv4 domain in the internet?

Best Regards,
Leaf

-----Original Message-----
From: Satoru Matsushima [mailto:[email-masked]] 
Sent: Tuesday, October 11, 2011 4:30 PM
To: Leaf yeh
Cc: Satoru Matsushima; Rémi Després; Ole Troan; Softwires-wg; [email-masked]
Subject: Re: [Softwires] Proposed Unified Address Mapping for encapsulation and double-translation

cheers,
--satoru

---

From: Satoru Matsushima <[email-masked]>
Date: Tue, 11 Oct 2011 20:25:27 +0900

> What is the definition of the IPv4 address in the above format? Is it the destination IPv4 address of any hosts outside 4rd IPv4 domain in the internet?

I believe that the embedded IPv4 address should be an IPv4 address of a host on outside the domain.

cheers,
--satoru

---

From: Satoru Matsushima <[email-masked]>
Date: Tue, 11 Oct 2011 22:39:44 +0900

On 2011/10/09, at 13:31, Maoke wrote:

> In case you need to embed the full IPv4 address for destination address in CE-BR, why not define a unified address format for CE-CE model. I think it would be easier to implement and easier to achieve further traffic identification in the same way.
> 
> 
> agree. 

I'd agree on that it could be appreciable for the hub and spoke scenario. I guess that the 'CE-CE' in the table indicates the mesh scenario.

cheers,
--satoru

---

From: Tetsuya Murakami <[email-masked]>
Date: Tue, 11 Oct 2011 16:35:03 -0700

+1.

From a developer point of view, I think there is a big impact on the current forwarding behavior on every major operating systems. In fact, I have never seen a similar implementation of any encapsulation/decapsulation so far.

Normally, the decapsulation could be done for the packet having the tunnel end-point address as the destination or having the specific IPv6 prefix as the destination. There is a big impact on the current implementation to look into a specific value in the last 64bit of IPv6 destination address. From the developer point of view, I would like to utilize the existing implementation as much as possible.

Thanks,
Tetsuya Murakami

---

From: Jacni Qin <[email-masked]>
Date: Wed, 12 Oct 2011 09:52:35 +0800

hi Satoru, Remi,

>> Now, putting the "CE IPv6 prefix length" back as a rule parameter shouldn't be a problem if the idea of linking IPv4 and IPv6 sizes of address spaces is abandoned (a choice that, I have to agree,…
Not "abandoned" actually, just not that tightly :-). L is not necessary 
by a CE when deriving its v4 space, since it would have got the length 
of prefix delegated to it (so, the L in the rule picked should match the 
length of delegated prefix). The sharing ratio is determined together by 
the L (Rule IPv6 prefix), L (Rule IPv4 prefix) and the L (delegated 
prefix). For example, for a given L (delegated prefix), the other two 
"L" can be changed to get different sharing ratios, or to maintain an 
identical sharing ratio within a domain even the L (delegated prefix) is 
variable.

L (in the matching rule based on IPv4 destination address) allows the CE 
to know the exact number of bits to pick from the port when forming the 
IPv6 destination address.

> I think that it should be exclusive in a domain but it could be coexist in the map specification.
Sorry, I don't quite follow, can you please say a little more?

Cheers,
Jacni

---

From: Tetsuya Murakami <[email-masked]>
Date: Tue, 11 Oct 2011 22:55:10 -0700

+1.

The above matrix is very clear to me.

In case of CE-BR, this case represents the traffic to the outside of the domain. In this case, I agree the full IPv4 destination address must be embedded in IPv6 destination address.

In case of CE-CE, this case represents the mesh communication between CEs. In this case, I don't think we need to embed full IPv4 destination address to IPv6 destination address. Because IPv6 destination address already includes enough information of IPv4 destination address (part of IPv4 address and port-set id).

From the implementation point of view, 4rd function checks if the destination is existed inside of the domain or outside of the domain at the first step. If the destination is inside of the domain, then 4rd function generates the IPv6 destination address from the IPv4 destination address or both IPv4 destination address and port. If the destination is outside of the domain, then 4rd function can generate the IPv6 destination address having the full IPv4 destination address. The process of the IPv6 address generation is different on each traffic case. Hence, I think 4rd function might be having the separated code for the destination address generation and either of code can be invoked according to the result of the first step check. In fact, our implementation is having the separated code for this IPv6 address generation.

In addition, if using the unified address format in CE-CE communication as well, some additional CPU cycles per packet are required at CE in order to embed the full IPv4 address (and port-set id) in the last 64bit of the IPv6 address.

Thanks,
Tetsuya Murakami

---

From: Maoke <[email-masked]>
Date: Wed, 12 Oct 2011 15:17:18 +0900

hi Tetsuya,

questions of trying to understand points, inline.

2011/10/12 Tetsuya Murakami <[email-masked]>

> In case of CE-BR, this case represents the traffic to the outside of the
> domain. In this case, I agree the full IPv4 destination address must be
> embedded in IPv6 destination address.
>
> In case of CE-CE, this case represents the mesh communication between CEs.
> In this case, I don't think we need to embed full IPv4 destination address
> to IPv6 destination address. Because IPv6 destination address already
> includes enough information of IPv4 destination address (part of IPv4
> address and port-set id).
>
> From the implementation point of view, 4rd function checks if the
> destination is existed inside of the domain or outside of the domain at the
> first step.

how does 4rd do the check? through routing table(s) or through all the
mapping rules which is either configured or distributed or learned?

> If the destination is inside of the domain, then 4rd function generates the
> IPv6 destination address from the IPv4 destination address or both IPv4
> destination address and port. If the destination is outside of the domain,
> then 4rd function can generate the IPv6 destination address having the full
> IPv4 destination address. The process of the IPv6 address generation is
> different on each traffic case. Hence, I think 4rd function might be having
> the separated code for the destination address generation and either of code
> can be invoked according to the result of the first step check. In fact, our
> implementation is having the separated code for this IPv6 address
> generation.

> In addition, if using the unified address format in CE-CE communication as
> well, some additional CPU cycles per packet are required at CE in order to
> embed the full IPv4 address (and port-set id) in the last 64bit of the IPv6
> address.
>
>
how many additional CPU cycles (or instructions) per packet will cost in
order to put things in the last 64bits?
does it not cost CPU cycles to check whether the destination exists inside
or outside of the domain? or it is not per-packet pace?

Thanks,

thanks and regards,
maoke

---

From: Leaf yeh <[email-masked]>
Date: Wed, 12 Oct 2011 07:24:57 +0000

Satoru -> I think we could have it.
Tetsuya Murakami -> the decapsulation could be done for the packet having the tunnel end-point address as the destination or having the specific IPv6 prefix as the destination.

Does that mean BR needs to inject a route pointing to the BR subnet prefix, and using one interface address of BR as the next-hop of this prefix in the route? That means routes can direct the packets go to the right interface of the BR, right?

Best Regards,
Leaf

-----Original Message-----
From: Satoru Matsushima [mailto:[email-masked]] 
Sent: Tuesday, October 11, 2011 7:25 PM
To: Leaf yeh
Cc: Satoru Matsushima; Rémi Després; Ole Troan; Softwires-wg; [email-masked]
Subject: Re: [Softwires] Proposed Unified Address Mapping for encapsulation and double-translation

cheers,
--satoru

---

From: Rémi Després <[email-masked]>
Date: Thu, 13 Oct 2011 11:06:07 +0200

> doable in theory, but I share your concerns.

Well, it wasn't quite right to say, as I did, "the 4rd function examines ALL packets that reach the CE".
More exactly, with existing kernel architectures, the 4rd function should only see packets that have the V octet in their IPv6 destinations.

With Linux, it is feasible AFAIK as follows:
- Before submitting a received packet to the routing function, it is submitted to the Netfilter pre-routing function. 
- Netfilter adds to the packet a mark, specific of 4rd, if it has the V  octet (mask + value).
- The routing function, duly configured, then sends packets that have this mark to the 4rd-function interface. 
With BSD, the PF packet filter has a role similar to that of Netfilter.
(Thanks to Francis Dupont for providing this information, hopefully not damaged by my transcription.)  

Useful capabilities of 4rd solutions SHOUDN'T therefore be abandoned for the unjustified fear that internal routing based on the V octet might be difficult.

Regards,
RD

---

From: Ole Troan <[email-masked]>
Date: Thu, 13 Oct 2011 11:08:13 +0200

Remi,

> Useful capabilities of 4rd solutions SHOUDN'T therefore be abandoned for the unjustified fear that internal routing based on the V octet might be difficult.

regardless of implementation, your proposal does add extra processing cycles for _all_ IPv6 packets to the site.

cheers,
Ole

---

From: Qiong <[email-masked]>
Date: Thu, 13 Oct 2011 22:03:31 +0800

Hi Leaf:

On Wed, Oct 12, 2011 at 3:24 PM, Leaf yeh <[email-masked]> wrote:

> Tetsuya Murakami -> the decapsulation could be done for the packet having
> the tunnel end-point address as the destination or having the specific IPv6
> prefix as the destination.
>
> Does that mean BR needs to inject a route pointing to the BR subnet prefix,
> and using one interface address of BR as the next-hop of this prefix in the
> route? That means routes can direct the packets go to the right interface of
> the BR, right?
>
> Yes. In case of using the specific BR IPv6 prefix, BR needs to inject a
routing and identifying with one interface as the next-hop. And this kind of
prefix can be distributed in a similar way of RFC6334.

 Best Regards,
> > Leaf -> In fact, I doubts we could have the same address mapping for both
> tunnel and translation. Supposed the address of tunnel end-points is
> preferred to be fixed, but the address for the translation could be
> variable.
> > What is the definition of the IPv4 address in the above format? Is it the
> destination IPv4 address of any hosts outside 4rd IPv4 domain in the
> internet?
>
> >> Ole - > putting the IPv4 address / port information at the end of the
> interface identifier will allow for > /64 support. > what's the L?
> > Since Remi's draft doesn't specify 'CE IPv6 prefix length', IPv6 prefix
> can't be self delimiting to extract IPv4 address and port-set ID in the case
> of double translation. That's my understanding. Is that correct?
> > As '4rd-a', and 4via6(draft-murakami-softwire-4v6-translation), the 'L'
> bits are not necessary because 'CE IPv6 prefix length' is defined through a
> domain, instead of 'L'.
> >
> >
> >>
> >> Ole - this is a big change for encapsulation, where prior to this
> encapsulation means sending to a single destination.
> >> Concern: Supposed the replacement of the 1st 64bits of the BR address
> with a subnet prefix is not for the tunnel case if the field of IPv4 address
> can be variable, right?
> >
> > I think that it could be a case where the BR address with a subnet prefix
> for the tunnel case. My concern rather than the BR address is that a CE
> should pick packets up which have 'V' in IID, even destined prefixes are
> delegated to nodes which are behind of the CE.
> >
> >
> >>
> >> In fact, I doubts we could have the same address mapping for both tunnel
> and translation. Supposed the address of tunnel end-points is preferred to
> be fixed, but the address for the translation could be variable.
> >>
> >
> >>> I do wonder if this has to be provisioned. e.g. some deployments may
> use the first subnet for the link between
>  (ref RFC 4291).
> >>>> An unambiguous mark is fortunately possible because currently
> permitted IIDs have in their first octet either bit6 = 0 (the "u" bit"), or
> bit6 = 1 and bit7= 0 (the "g" bit).
> distinction is therefore deterministic.
> >>>>
> case some would be useful in the future.)
> >>>>
> >>>> Note that, if and when a consensus is reached in Softwire, an
> extension of RFC 4291 will have to be submitted to 6MAN.
> >>>
> >>> or rather IEEE?
> >>
> >> IMHO, IEEE has nothing to do with a marker that is purposely an escape
> mechanism from the modified EUI-64 format of RFC 4291.
> >>
> >> Reason is that we are working for a consensus, and several are satisfied
> with the explanation that there are use cases where it is useful, and none
> where it is harmful.
> >>
> >>> this is a big change for encapsulation, where prior to this
> encapsulation means sending to a single destination.
> >>
> >>>> Note that if double-translation CEs are notified to use U instead of
> V, the last octet becomes 0 per RFC  6052.
> >>>
> >> May I suggest that, to be more constructive, you could first express
> your objections to the proposed unified mapping, rather than making a number
> of new proposals whose justifications are sometimes hard to understand,
> >>
> >> Cheers,
> >> RD
> >>
> >>
> >>>
> >>> cheers,
> >>> Ole
> >>>
> >>>

---

From: Leaf yeh <[email-masked]>
Date: Mon, 17 Oct 2011 11:12:36 +0000

I'd like to add one more row in the below table, then let it look like as follows.

|  CE-CE   |                 |                    |
|  CE-BR   |                 |        Yes         |
|  BR-CE   |                 |                    |

And one more question for you: Do you think it is really necessary to include the case while CE 4rd prefix (defined in draft-murakami-softwire-4rd-01) or CE generalized IPv4 prefix (defined in draft-despres-softwire-4rd-addmapping-01) is less than 32 bits, which sounds CE has been assigned a IPv4 subnet?

Best Regards,
Leaf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tetsuya Murakami
Sent: Wednesday, October 12, 2011 1:55 PM
To: GangChen
Cc: Softwires-wg
Subject: Re: [Softwires] Proposed Unified Address Mapping for encapsulation and double-translation

+1.

Thanks,
Tetsuya Murakami

---

From: Rémi Després <[email-masked]>
Date: Mon, 17 Oct 2011 18:21:19 +0200

Hi Maoke,

On 2011/10/12, you wrote:
"... considering the double translation is a case of translation. it is possible that a src host with an IPv4-translatable IPv6 address generates a fragment header with a 32-bit identifier happening to have the first 16 bit as either 0x8000 or 0x0000, making a fake D bit in your current proposal."

An important point is that the IP identifier needs to be unique ONLY for each <SRC, DST> pair.
If 4rd addresses are deterministically recognizable (with the V octet in bits 64-71), there is no risk of confusion with an IP identification generated for another purpose than 4rd.

Hope it clarifies.

Cheers,
RD

---

From: Maoke <[email-masked]>
Date: Tue, 18 Oct 2011 11:37:55 +0900

hi Remi,

2011/10/18 Rémi Després <[email-masked]>

> "... considering the double translation is a case of translation. it is
> possible that a src host with an IPv4-translatable IPv6 address generates a
> fragment header with a 32-bit identifier happening to have the first 16 bit
> as either 0x8000 or 0x0000, making a fake D bit in your current proposal."
>
> If 4rd addresses are deterministically recognizable (with the V octet in
> bits 64-71), there is no risk of confusion with an IP identification
> generated for another purpose than 4rd.
>

thus i understand. then you didn't try to decouple the header processing
from the mapping algorithm, right? sorry but i was confused here. :P

best,
maoke

---

From: Rémi Després <[email-masked]>
Date: Tue, 18 Oct 2011 09:43:57 +0200

Le 18 oct. 2011 à 04:37, Maoke a écrit :

> thus i understand. then you didn't try to decouple the header processing from the mapping algorithm, right? sorry but i was confused here. :P

The 4rd-U header format builds on a useful property of the address mapping algorithm, the fact that <SRC, DST> pairs of 4rd packets are distinguishable from those of native IPv6 packets.
Other than that, it doesn't depend on any particular address mapping. 

With RFC 6052, for instance, addresses that have the well-known or network-specific prefixes are recognizable as being IPv4-embedded addresses? They are therefore compatible with the 4rd-U header format. (It remains that the V octet is AFAIK easier for O&M, and permits to have the same CE IPv6 prefix for native IPv6 and embedded IPv4, a useful property for some use cases).

I should have made this clearer, thanks for your remark. 

Cheers,
RD