Subject: Re: [Softwires] 4rd Address Mapping - version-01

From: xiaohong deng <[email-masked]>
Date: Tue, 4 Oct 2011 15:26:00 +0800

Hi Remi, Ole, Woj, and all,

I understand the argument of IID bits is resulted from a last minute
agreement between 4rd and divi-pd people that having full IPv4 address
embedded in the address format helps source based classification, but
before we argue that, shall we first make this agreement also be
accepted by community wide? As far as current time-being concerned, I
don't see a consensus has been reached on this agreement from
community wide.

It IMHO would be helpful if anybody would clarify some details to 1)
first prove source based classification is either a valid or a
non-valid requirement for address mapping; For this regard, I would
begin with that why do we think the source based IPv4 classification
ability instead of the more general five-tuple based IPv4
classification ability should be reserved, when deliver IPv4 over
IPv6?

and 2) then show us how much other efforts are required to achieve so
besides address format definition itself, in other words, if it's a
valid requirement, let's first have feasibility of this requirement
analyzed from both deployment and operational perspectives:

1. For double translation, how does a traditional router perform the
source based IPv4 packet classification on IPv6 (translated from IPv4)
packets? Or does it suggest that using IPv6 classification filters to
filter IPv4 packets? If so, should we also note that this suggests
IPv4 operation and managed are tightly coupled with IPv6 operation and
management? which in turn implies complexity in operational, or put in
other words, OPEX increasing, the last thing among others that
operators would like to see.

2. For encapsulation, even if embedding source IPv4 addresses in the
lower bits of the address formats, where does the router find the
source port without de-capsulation? Are you suggesting also encode 16
bits port in the lower part of address? In either case, it leads to
the concerns of increased OPEX to operators stated above.

Thoughts?

Cheers,
Xiaohong

> Hi Qiong,
>
> Some fields of a unified address format for double translation and
> encapsulation might be unnecessary for hub and spoke, but using the
> same format should be advantageous for maintenance and training if for
> nothing else (assuming that any added complexity is negligible
> enough).
>
> Believing that a completely unified format is possible, I mentioned it to Alain.
> Also, I volunteered to be editor-coordinator for this to happen, but
> decision of who does what is his.
>
> Regards,
> RD
>
>
> Le 4 oct. 2011 à 00:13, Qiong a écrit :
>
>> Hi Remi and Wojciech,
>>
>> Thanks for your clarification. I fully agree with you that embedding the full IPv4 address in the last 64 bits would be quite helpful for some kind of source address classification and I also suggest that this can be taken in the same way for encapsulation-based approach. It would be easier for systems in-the-middle to identify the IPv4 address without packet decapsulation.
>>
>> I guess the thing that Ole has mentioned to "look at 24 bits in the middle of IPv6 address" is for CE to determine whether a downstream IPv6 packet should be taken for translation or native forwarding. Here, for a dual-stack host, there would be no difference in the first /64 bits for a native IPv6 packet and a translated packet. What's why the CE should further looking into the last 64 bits to determine the translation process or native forwarding. Maybe Ole can clarify for this part again.
>>
>> However, the situation would still be different in "Hub & Spoke" and "Mesh" mode. For Hub & Spoke case, since BR will have a default prefix/address, it would be easily to identify the translated traffic from native IPv6 traffic by just doing source address routing lookup for a downstream packet. So, the corresponding mechanics would be different.
>>
>> Thanks
>>
>> Best wishes
>>
>> Qiong
>>
>> 2011/10/3 Wojciech Dec <wdec at cisco.com>
>>
>>
>>
>>
>>     On 02/10/2011 02:58, "Qiong" <bingxuere at gmail.com> wrote:
>>
>>         Hi Ole and Remi,
>>
>>             > This is my answer to your first (double) question.
>>             > If it is not enough, as suggested below, please explain what you don't understand.
>>
>>             I specifically do not want a solution that changes forwarding behaviour for _all_ IPv6 packets.
>>             e.g. looking at 24 bits in the middle of an IPv6 address is such a change.
>>
>>             Woj> What are you referring to? Routing “just works” as normal and is non disaggregated because of the CE-index in the prefix. Classification can/is done on a subset of the v6 address, and that is perfectly legit.
>>
>>
>>             I don't understand what requirements you are basing this 'solution' on.
>>             if the 4rd / dIVI CE takes (a well known or provisioned) /64 prefix out of the delegated prefix. then why do you need any of that?
>>
>>
>>         Qiong : I agree that routing lookup for a provisioned /64 prefix would be better that extracting certain bits for each IPv6 address in CE. This would bring less change to existing routing model.
>>
>>         Woj> There is no change to the existing destination based routing model. Each CE is uniquely addressed by the CE bits in the top /64 – ie the CE index is as proposed by all the 4rd and divi-pd drafts. The full v4 source address of each CE is however also embedded in the interface-id, as per RFC6052. There appears to be no cost for this operation, and has the upside of the full v4 info visible in the header and allowing source based classification (should one want to do that).
>>
>>         Regards,
>>         Woj.
>>
>>         Best wishes
>>
>>         Qiong
>>
>>             _______________________________________________
>>             Softwires mailing list
>>             Softwires at ietf.org
>>             https://www.ietf.org/mailman/listinfo/softwires
>>
>>
>>
>

---

From: Rémi Després <[email-masked]>
Date: Tue, 4 Oct 2011 10:34:44 +0800

Xiaohong,

Thanks for you contribution for this debate.
More below.

Le 4 oct. 2011 à 15:26, xiaohong deng a écrit :

> embedded in the address format helps source based classification,

The agreement is just between those who participated.
In no way does it commit the group to anything.

Yet I believed it was useful to inform the group that something was found possible, in common by some proponents of encapsulation and double-translation solutions.

> but
> accepted by community wide?

No WG agreement can obviously be reached before an open exchange of views.
Exchanging arguments is a necessary part of this process. 

> As far as current time-being concerned, I

Very clear.

> classification ability should be reserved, when deliver IPv4 over

After having checked details of our common understanding with Xing, Congxiao and Wojciech, I will very soon communicate what we found promising.
Sorry for the time it took us.

> filter IPv4 packets?

The latter was my understanding.
With it, filters on IPv4-address, and IPv4-shared-addreses, can be exercised in existing devices if having appropriately configured IPv6-address filters.
If this can be achieved with negligible capex and opex costs, and without obligation to do it, why not? 

> If so, should we also note that this suggests
> other words,

> OPEX increasing, the last thing among others that

Indeed, keeping in mind also that a single well chosen standard tends to reduce overall costs.

> the concerns of increased OPEX to operators stated above.

An expectation is that copying an available information into a fixed part of an IID shouldn't be expensive at all, and that having IPv4 addresses and port-set IDs in clear form in IPv6 addresses should facilitate maintenance, even if no filter is configured.

Cheers,
RD

---

From: Wojciech Dec <[email-masked]>
Date: Tue, 04 Oct 2011 10:41:41 +0200

Hello Xiaohong,

> don't see a consensus has been reached on this agreement from

Indeed, but we're hopefully close.

> classification ability should be reserved, when deliver IPv4 over

Could you explain a bit more what you mean by "general five-tuple based IPv4
classification should be reserved, when deliver IPv4 over IPv6"?

>From my side, as I think was outlined earlier, the embedding of the source
addresses in the IID is desirable in order to have the full original IPv4 L3
at the IPv6 L3 level. If I interpret your five-tuple classification notion,
then this mapping provides exactly such capability for the translation case,
and comes at no-cost. At the interim meeting we agreed that the mapping
scheme needs to be unified and work for both encap and translation - this
one does. What is your alternative proposal?

> operators would like to see.

This was discussed at the interim meeting - presentations from Hui and Xing
come to mind. I think it is fair to state that there are those operators who
believe strongly that having an IPv6 mapped representation of IPv4
addressing allows the use of IPv6 only data plane devices and provisioning
tools, which LOWERS the difficulty of deployment and Opex, as opposed to
having to upgrade routers and systems to manage an IPv4 data-plane over IPv6
- that would truly be extra opex. Some other operators may care less about
this, but this does not detract from the case of those that do.

> the concerns of increased OPEX to operators stated above.

I don't see how this argument applies - the information to derive the
information that needs to be mapped is "automatic" and comes for free with
the algorithms. Perhaps it is useful to note that the "encapsulating router"
needs to look at L4 info anyway. Similarly, the full IPv4 address and
port-set-id is available for each packet passed by the router. Placing that
info in the IID, or any other set of bits is, computationally the same.

Regards,
Woj.
>>> Thanks for your clarification. I fully agree with you that embedding the
>>> full IPv4 address in the last 64 bits would be quite helpful for some kind
>>> of source address classification and I also suggest that this can be taken
>>> in the same way for encapsulation-based approach. It would be easier for
>>> systems in-the-middle to identify the IPv4 address without packet
>>> decapsulation.
>>> 
>>> I guess the thing that Ole has mentioned to "look at 24 bits in the middle
>>> of IPv6 address" is for CE to determine whether a downstream IPv6 packet
>>> should be taken for translation or native forwarding. Here, for a dual-stack
>>> host, there would be no difference in the first /64 bits for a native IPv6
>>> packet and a translated packet. What's why the CE should further looking
>>> into the last 64 bits to determine the translation process or native
>>> forwarding. Maybe Ole can clarify for this part again.
>>> 
>>> However, the situation would still be different in "Hub & Spoke" and "Mesh"
>>> mode. For Hub & Spoke case, since BR will have a default prefix/address, it
>>> would be easily to identify the translated traffic from native IPv6 traffic
>>> by just doing source address routing lookup for a downstream packet. So, the
>>> corresponding mechanics would be different.
>>> 
>>> Thanks
>>> 
>>> Best wishes
>>> 
>>> Qiong
>>> 
>>>             Woj> What are you referring to? Routing ³just works² as normal
>>> and is non disaggregated because of the CE-index in the prefix.
>>> Classification can/is done on a subset of the v6 address, and that is
>>> perfectly legit.
>>> 
>>> 
>>>             if the 4rd / dIVI CE takes (a well known or provisioned) /64
>>> prefix out of the delegated prefix. then why do you need any of that?
>>> 
>>> 
>>>         Qiong : I agree that routing lookup for a provisioned /64 prefix
>>> would be better that extracting certain bits for each IPv6 address in CE.
>>> This would bring less change to existing routing model.
>>> 
>>>         Woj> There is no change to the existing destination based routing
>>> model. Each CE is uniquely addressed by the CE bits in the top /64  ie the
>>> CE index is as proposed by all the 4rd and divi-pd drafts. The full v4
>>> source address of each CE is however also embedded in the interface-id, as
>>> per RFC6052. There appears to be no cost for this operation, and has the
>>> upside of the full v4 info visible in the header and allowing source based
>>> classification (should one want to do that).
>>> 
>>>         Regards,
>>>         Woj.
>>> 
>>>         Best wishes
>>> 
>>>         Qiong
>>>

---

From: xiaohong deng <[email-masked]>
Date: Tue, 4 Oct 2011 17:33:14 +0800

Remi,

Appreciations to you too for your taking initiative.

More inline.

> Yet I believed it was useful to inform the group that something was found possible, in common by some proponents of encapsulation and double-translation solutions.

Absolutely.

> Exchanging arguments is a necessary part of this process.

Exactly, and that's the reason why I threw this discussion.

> Sorry for the time it took us.

Well. Stay tunned, and expect to hearing more..

> With it, filters on IPv4-address, and IPv4-shared-addreses, can be exercised in existing devices if having appropriately configured IPv6-address filters.

Share the same understanding with you, yet seems we're still in the
guessing each other's idea stage; However once an agreement of this
requirement reached, I suppose it is fair to state it somewhere
explicitly how this (filtering IPv4 by IPv6 filters) works for the
sake of clarification, and of easing future deployment: for example,
maybe generating IPv6 filters from IPv4 address and/or ports would be
defined/implemented with devices somewhere in future. Just imagine who
could bear with calculating each IPv6 filters manually from IPv4..

> If this can be achieved with negligible capex and opex costs, and without obligation to do it, why not?

Well said.

Since it has been widely aware that migration to IPv6 costs, no matter
at opex or capex cost, and operators can choose approaches at
acceptable costs on both, increased opex should not be an argument
against any approach, yet stating the potential somewhere makes
operators' lives easier.

> Indeed, keeping in mind also that a single well chosen standard tends to reduce overall costs.

Agreed, as long as it's feasible.

> An expectation is that copying an available information into a fixed part of an IID shouldn't be expensive at all, and that having IPv4 addresses and port-set IDs in clear form in IPv6 addresses sh…

Fully agreed with this point, but only question that if the source
address filtering is only what we want to perseve? What about
five-tuple (source address, source port, destination address,
destination port, protocol) filtering?

Cheers,
Xiaohong

---

From: Rémi Després <[email-masked]>
Date: Tue, 4 Oct 2011 15:31:07 +0800

Hi Xing, Congxiao,

...
> classification ability should be reserved, when deliver IPv4 over

What about starting from your conclusion slide in Beijing?

It says:

"dIVI/dIVI-PD can use existing tools for O&M
– Null route
– ACL
– eACL
– PBR
– QoS
– Caching"

Open questions include:
- Which addresses are used for these O&M functions? (source? destination?, CE to CE?, CE to BR?, BR to CE?)
- Are ports within IPv6 payloads used, or just addresses?

Thank you if you can share your views on this.

Regards,
RD

---

From: Congxiao Bao <[email-masked]>
Date: Tue, 4 Oct 2011 23:37:44 +0800

Hi Remi,

Ok, we will draft a document on using existing tools for O&M in dIVI/dIVI-PD
very soon.

Best,

Congxiao

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

> [email-masked]

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Tue, 4 Oct 2011 14:28:27 -0500

> classification ability should be reserved, when deliver IPv4 over

How would one get 5-tuple based classification when delivering IPv4 "over" IPv6, if the v4 packet is not translated into v6?

The fact of the matter is that "5-tuple" could be a luxury that may not always be available.

Cheers,
Rajiv

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of xiaohong deng
> Sent: Tuesday, October 04, 2011 3:26 AM
> To: Wojciech Dec (wdec); [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: [Softwires] 4rd Address Mapping - version-01
> 
> full IPv4 address in the last 64 bits would be quite helpful for some kind of
> source address classification and I also suggest that this can be taken in the
> same way for encapsulation-based approach. It would be easier for systems in-
> the-middle to identify the IPv4 address without packet decapsulation.
> >>
> packet and a translated packet. What's why the CE should further looking into
> the last 64 bits to determine the translation process or native forwarding.
> Maybe Ole can clarify for this part again.
> >>
> would be easily to identify the translated traffic from native IPv6 traffic by
> just doing source address routing lookup for a downstream packet. So, the
> >>             Woj> What are you referring to? Routing "just works" as normal
> and is non disaggregated because of the CE-index in the prefix. Classification
> can/is done on a subset of the v6 address, and that is perfectly legit.
> >>
> >>
> would be better that extracting certain bits for each IPv6 address in CE. This
> would bring less change to existing routing model.
> >>
> model. Each CE is uniquely addressed by the CE bits in the top /64 - ie the CE
> index is as proposed by all the 4rd and divi-pd drafts. The full v4 source
> address of each CE is however also embedded in the interface-id, as per
> RFC6052. There appears to be no cost for this operation, and has the upside of
> the full v4 info visible in the header and allowing source based

---

From: Xing Li <[email-masked]>
Date: Wed, 05 Oct 2011 15:15:25 +0800

> How would one get 5-tuple based classification when delivering IPv4 "over" IPv6, if the v4 packet is not translated into v6?

Yes, this is why we need the whole IPv4 address plus port ID in the IPv6 
address. xing

>>>> However, the situation would still be different in "Hub&  Spoke" and "Mesh"
>> mode. For Hub&  Spoke case, since BR will have a default prefix/address, it
>>>> 2011/10/3 Wojciech Dec<wdec at cisco.com>
>>>>
>>>>
>>>>
>>>>
>>>>      On 02/10/2011 02:58, "Qiong"<bingxuere at gmail.com>  wrote:
>>>>
>>>>          Hi Ole and Remi,
>>>>

---

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

> The fact of the matter is that "5-tuple" could be a luxury that may not always be available.

Questions for clarification about 5-tuple-based actions of intermediate nodes that are currently used:
- Do we know whether they generally work with IPv6 packets having extension headers?
- If yes, with which ones?
- In particular, are fragment headers always supported (with ports available only in first fragments)?

Thanks,
RD

---

From: xiaohong deng <[email-masked]>
Date: Thu, 6 Oct 2011 16:58:59 +0800

> - In particular, are fragment headers always supported (with ports available only in first fragments)?

Curious and look forward to clarifications to above too.

Thanks,
Xiaohong

---

From: xiaohong deng <[email-masked]>
Date: Thu, 6 Oct 2011 17:11:41 +0800

> Ok, we will draft a document on using existing tools for O&M in dIVI/dIVI-PD

Thanks for sharing and look forward to it.

Cheers,
Xiaohong

---

From: Congxiao Bao <[email-masked]>
Date: Tue, 04 Oct 2011 23:32:24 +0800

Hi Remi,

Ok, we will draft a document on using existing tools for O&M in 
dIVI/dIVI-PD very soon.

Best,

Congxiao