Subject: [Softwires] Motivation draft for stateless v4 over v6 solution

From: Satoru Matsushima <[email-masked]>
Date: Fri, 6 May 2011 19:39:55 +0900

Dear colleague, 

We've uploaded an I-D to express our motivation of stateless IPv4 over IPv6 as an IPv6 transition solution. Since the outcome of recharter session in last softwires wg meeting, ADs required the motivation draft to standardize stateless v4 over v6 solution at IETF.

We, authors of the draft, have been trying to clearly explain our motivation, scope, and current open questions for stateless solution as much as possible in this draft. We believe that it should be helpful to understand what our motivation is.

Please find it out from following url:
http://www.ietf.org/id/draft-operators-softwire-stateless-4v6-motivation-00.txt

We'd like to have your kind review, and comments, also welcome to discuss about the motivation in the softwires mailing list.

Best regards,
--satoru

---

From: <[email-masked]>
Date: Mon, 9 May 2011 13:38:16 +0200

Hi Rémi,

Thank you for the comments.

Please see inline.

Cheers,
Med 

-----Message d'origine-----
De : Rémi Després [mailto:[email-masked]] 
Envoyé : lundi 9 mai 2011 11:10
À : Satoru Matsushima; BOUCADAIR Mohamed OLNC/NAD/TIP; Yiu Lee; Olaf Bonness; Isabel Borges
Cc : Softwires-wg
Objet : Re: [Softwires] Motivation draft for stateless v4 over v6 solution

Satoru-san, Med, all authors,

Congratulation for this important I-D, and for the quick convergence among all of you. 

Here are, after a detailed review, some remarks:

1. Sec 2 - Terminology (and some other instances of "port range")

"Port space", as used in sec. 5.3, or "port set", would be more appropriate than "port range" in a motivation document because:
- A port range is a particular case of port set or port space, but not the reverse.
- At least one documented solution uses port sets that contain several port ranges.

Med: I don't see much the difference between a port range and a port set. IMO, what is important is to use consistent terminology in the document. Do you have any pointer (other that the solution document you are referring to) where "port set" is defined? If needed, I can update the text to state that both "port range" and "port set" are used interchangeably.

2. Sec 3. IPv4 Service Use case

While the "Host based model is out of scope", it would be IMHO good to note that:
"The model can however apply to any host that includes a CPE function".

Med: I prefer having the explicit statement to say the host-based model is out of scope.

5.1. Dependency Between IPv4 and IPv6 Address Assignments

The I-D says "Providing two IPv6 prefixes avoids the complexity related to the adaptation of the IPv6 addressing scheme to the IPv4 addressing scheme".
But some solutions don't require to adapt the IPv6 addressing scheme to that of IPv4.
(A particular example is described in sec 3.2 of draft-despres-softwire-sam-01. With it, several IPv4 prefixes are supported without any impact on the IPv6 addressing scheme)
Suggestion: after "complexity", add "that may be".

Med: Done. FWIW, I also updated that section with a comment received from R. Maglione:

"For Service Providers requiring to apply specific policies on per Address-Family (e.g., IPv4, IPv6), some provisioning tools (e.g., DHCPv6 option) may be required to derive in a deterministic way the IPv6 address to be used for the IPv4 traffic based on the IPv6 prefix delegated to the home network. "

5.3. Port Randomization

The I-D says "Other means than the (IPv4) source port randomization to provide protection against attacks should be used (e.g., use
[I-D.vixie-dnsext-dns0x20] to protect against DNS attacks, [RFC5961] to improve the robustness of TCP against Blind In-Window Attacks)".

However:
- The solution cited as example is from an expired  I-D.
- Another solution is that the DNS server of the operator be accessible in IPv6, and that the CPE translates IPv4 DNS queries to send them to this server. In this case, no port-set restriction applies.
Suggestion: 
- Delete the paragraph, or,
- Note that IPv6 DNS servers is a solution (and avoid the reference to I-D.vixie-dnsext-dns0x20).

Med: I updated the text to mention that using IPv6 is one of the solutions.

I think this I-D should become asap a WG draft.
(This would preferably be with some improvements like those proposed above, but this isn't IMHO a prerequisite.)

The sooner it reaches RFC status, the better. 

Regards,
RD

Le 6 mai 2011 à 12:39, Satoru Matsushima a écrit :

> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires

---

From: <[email-masked]>
Date: Mon, 9 May 2011 15:37:24 +0200

Re-,

Please see inline.

Cheers,
Med 

-----Message d'origine-----
De : Rémi Després [mailto:[email-masked]] 
Envoyé : lundi 9 mai 2011 14:42
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : Satoru Matsushima; Yiu Lee; Olaf Bonness; Isabel Borges; Softwires-wg
Objet : Re: [Softwires] Motivation draft for stateless v4 over v6 solution

Med,

Thank you for the quick reaction.
More in line.
 
Le 9 mai 2011 à 13:38, <[email-masked]> a écrit :

> Med: I don't see much the difference between a port range and a port set.

A range is between two limits.
A set of ports defined by several non-overlapping prefixes cannot therefore be called a range. 
 
> IMO, what is important is to use consistent terminology in the document.

Same view.

> Do you have any pointer (other that the solution document you are referring to) where "port set" is defined?

Not that I know, but a port set is self explanatory (nothing more than a set of ports). 

> If needed, I can update the text to state that both "port range" and "port set" are used interchangeably.

New suggestion, hopefully better: replace, throughout the document, "port range" by "port range or port set".

Med: For the sake of easing the readability of the document, I added "Within this document "port set" and "port range" are used interchangeably." instead of repeating each time both terms.

> Med: I prefer having the explicit statement to say the host-based model is out of scope.

Same view.
The intended proposal wasn't to delete this sentence (sorry if it wasn't clear enough).
It is just to add the new sentence after it.

Med: One can consider a host embedding a CPE function as a router, no?

> Med: Done.

Thanks.

> FWIW, I also updated that section with a comment received from R. Maglione:
> 

Thanks.

---

From: Satoru Matsushima <[email-masked]>
Date: Mon, 9 May 2011 22:36:51 +0900

Hi Remi-san,

Thanks, I'd like to clarify about:

> It is just to add the new sentence after it.

Since CPE is acronym of "Customer Premised Equipment", which means that specifying where the equipment installed. It sounds different term from what we've discussed about deployment model. Remi-san seem to point out a function of customer edge. Is that correct?

Best regards,
--satoru

---

From: <[email-masked]>
Date: Tue, 10 May 2011 07:57:03 +0200

Hi Rémi,

I understand your point but, and speaking as individual author of the draft, my organization does not recommend for the mobile context for instance any transition solution requiring specific functions in the host (this is also the position of the 3GPP IPv6 SI). The main reason is, unlike the CPE case, we don't control the host.

Cheers,
Med 

-----Message d'origine-----
De : Rémi Després [mailto:[email-masked]] 
Envoyé : lundi 9 mai 2011 18:37
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : Satoru Matsushima; Yiu Lee; Olaf Bonness; Isabel Borges; Softwires-wg
Objet : Re: [Softwires] Motivation draft for stateless v4 over v6 solution

Le 9 mai 2011 à 15:37, <[email-masked]> <[email-masked]> a écrit :
> ...

"Port set" throughout would IMHO have been better, but what you added is good enough.
Thanks.

> Med: One can consider a host embedding a CPE function as a router, no?

Some clarification may be needed for a common understanding.
In the DS-lite draft, we have, concerning the host-based architecture:
"This architecture is targeted at new, large scale deployments of dual-stack capable devices implementing a dual-stack lite interface."

I don't see why the stateless solution couldn't have a host-based variant "targeted at new, large scale deployments of dual-stack capable devices implementing" the CPE router function.

Just saying "host-based models are out of scope" seems to me more negative than needed.

The host-based DS-lite architecture is illustrated by:
"              +-------------------+
               |                   |
               |  Host 192.0.0.2   |
               |+--------+--------+|
               ||        B4       ||
               |+--------+--------+|
               +--------|||--------+
                        |||2001:db8:0:1::1
                        |||
                        |||<-IPv4-in-IPv6 softwire
                        |||
                 -------|||-------
               /        |||        \
              |   ISP core network  |
               \        |||        /
                 -------|||-------
                        |||
                        |||2001:db8:0:2::1
               +--------|||--------+
               |       AFTR        |
               |+--------+--------+|
               ||  Concentrator   ||
               |+--------+--------+|
               |       |NAT|       |
               |       +-+-+       |
               +---------|---------+
                         |192.0.2.1
                         |
                 --------|--------
               /         |         \
              |       Internet      |
               \         |         /
                 --------|--------
                         |
                         |198.51.100.1
                   +-----+-----+
                   | IPv4 Host |
                   +-----------+          "

The host-based stateless-IPv4/IPv6 architecture can similarly be illustrated by.
"              +-------------------+
               |       Host        |
               | RFC 1918 address  |
               |+--------+--------+|
               || Stateless v4/v6 ||
               ||  CPE function   ||
               || (incl. NAPT44)  ||
               |+--------+--------+|
               +--------|||--------+
                        |||2001:db8:0:1::1
                        |||
                        |||<-IPv4-in-IPv6 stateless
                        |||
                 -------|||-------
               /        |||        \
              |   ISP core network  |
               \        |||        /
                 -------|||-------
                        |||
                        |||2001:db8:0:2::1 
               +--------|||--------+
               |     Stateless     |
               |    IPv4/IPv6      |
               |  interconnection  |
               |     function      |
               +---------|---------+
                         |192.0.2.1
                         |
                 --------|--------
               /         |         \
              |       Internet      |
               \         |         /
                 --------|--------
                         |
                         |198.51.100.1
                   +-----+-----+
                   | IPv4 Host |
                   +-----------+          "

Am I missing something?

Regards,
RD

---

From: Satoru Matsushima <[email-masked]>
Date: Tue, 10 May 2011 15:27:56 +0900

Remi-san has simply pointed out that the service use case section of the draft assumes same implication in the ds-lite draft. I think that it would be no problem, and better to just remove the use case section, because the draft already expressed it as target space table in the introduction.

Best regards,
--satoru

---

From: Jacni Qin <[email-masked]>
Date: Tue, 10 May 2011 15:55:10 +0800

Re-,

Just to confirm it, only 4-4 and 6-6 are covered, no 4-6, right?

Cheers,
Jacni

On Tue, May 10, 2011 at 2:27 PM, Satoru Matsushima <
[email-masked]> wrote:

> Remi-san has simply pointed out that the service use case section of the
> draft assumes same implication in the ds-lite draft. I think that it would
> be no problem, and better to just remove the use case section, because the
> draft already expressed it as target space table in the introduction.
>
> Best regards,
> --satoru
>
>

---

From: Satoru Matsushima <[email-masked]>
Date: Tue, 10 May 2011 16:58:17 +0900

Hi,

This is a draft submitted to softwires. Why not?

--satoru

On 2011/05/10, at 16:55, Jacni Qin wrote:

> On Tue, May 10, 2011 at 2:27 PM, Satoru Matsushima <[email-masked]> wrote:

---

From: Ole Troan <[email-masked]>
Date: Thu, 26 May 2011 10:36:12 +0200

I like the draft and I think it covers the motivational points well.

as a general comment, I do think the document is too wordy. could the authors make the next revision terser or do you want me to propose text changes?

I would also suggest that you reference the sections in rfc1958 on state.
we don't have a good success record in gleaning state in the middle of the network (NAT, N:1 VLANs, DHCP...), since the protocols we 'glean' from aren't designed to maintain softstate in the network.

I see no reason why this document shouldn't be adopted as a working group document immediately.

cheers,
Ole

---

From: Mark Townsley <[email-masked]>
Date: Thu, 26 May 2011 11:41:47 +0200

> I see no reason why this document shouldn't be adopted as a working group document immediately.

I support this becoming a WG document, and agree with Ole that the next version should cut back on text. We want to give the IESG something as clear and concise as possible.

If there is reasonable consensus (not that the document is complete, but that it will be the basis for the final document), all it takes is an OK by the chairs and a submission by the authors with the WG title. 

- Mark

---

From: <[email-masked]>
Date: Thu, 26 May 2011 13:25:12 +0200

Dear Ole,

For sure, the text can be shortened whenever possible. 

If you point me to sections you think it need to be re-worded, this would be appreciated.

Thank you.

Cheers,
Med 

-----Message d'origine-----
De : Ole Troan [mailto:[email-masked]] De la part de Ole Troan
Envoyé : jeudi 26 mai 2011 10:36
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : Rémi Després; Satoru Matsushima; Yiu Lee; Olaf Bonness; Isabel Borges; Softwires-wg
Objet : Re: [Softwires] Motivation draft for stateless v4 over v6 solution

cheers,
Ole

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 26 May 2011 11:19:23 -0700 (PDT)

> > as a  general comment, I do think the document is too wordy. could the 
>authors make  the next revision terser or do you want me to propose text 
>changes?
> > 
> > we don't have a good success record in gleaning state in the  middle of the 
>network (NAT, N:1 VLANs, DHCP...), since the protocols we 'glean'  from aren't 
>designed to maintain softstate in the network.
> > 
> I support this becoming a WG document, and agree with Ole  that the next 
>version should cut back on text. We want to give the IESG  something as clear 
>and concise as possible.
> 
> If there is reasonable  consensus (not that the document is complete, but that 
>it will be the basis for  the final document), all it takes is an OK by the 
>chairs and a submission by the  authors with the WG title. 
>
> 

You mean after merging with draft-chen-softwire-4v6-motivation-00.txt?

then +1 from me.

Behcet

---

From: Jacni Qin <[email-masked]>
Date: Fri, 27 May 2011 16:54:36 +0800

> authors make the next revision terser or do you want me to propose text

Jacni>: Yes, a little. Too many operational issues, is there any order of
priority? Or just point out what you concern the most?
I felt lost after reading it. :-)

> network (NAT, N:1 VLANs, DHCP...), since the protocols we 'glean' from
> aren't designed to maintain softstate in the network.
>

Jacni>: +1

Cheers,
Jacni

---

From: Satoru Matsushima <[email-masked]>
Date: Tue, 31 May 2011 00:48:47 +0900

Hi,

> You mean after merging with draft-chen-softwire-4v6-motivation-00.txt?

The authors of both drafts are now co-working to integrate unified version so we'll submit it soon. We would like to invite your comments. Any feedback for current version of both draft are also welcome.

Best regards,
--satoru