Subject: [Softwires] MAP compatibility with DS-Lite

From: Simon Perreault <[email-masked]>
Date: Wed, 20 Nov 2013 14:54:20 -0500

WG,

draft-ietf-softwire-map-08 contains this:

7.3. Backwards compatibility

    A MAP-E CE provisioned with only the IPv6 address of the BR, and with
    no IPv4 address and port range configured by other means, MUST
    disable its NAT44 functionality.  This characteristic makes a MAP CE
    compatible with DS-Lite [RFC6333] AFTRs, whose addresses are
    configured as the MAP BR.

In view of the recent discussions on provisioning, this functionality 
strikes me as useless. There would be no reason for an ISP to use such 
provisioning. A unified CPE would just do DS-Lite if that's what's 
available.

I suggest to remove that section.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Ole Troan <[email-masked]>
Date: Wed, 20 Nov 2013 22:32:23 +0100

Simon,

> In view of the recent discussions on provisioning, this functionality strikes me as useless. There would be no reason for an ISP to use such provisioning. A unified CPE would just do DS-Lite if that's what's available.
> 

I tend to agree with that.

cheers,
Ole

---

From: Wojciech Dec <[email-masked]>
Date: Fri, 22 Nov 2013 11:30:28 +0100

> I suggest to remove that section.

You seem to equate ds-lite to being only there if it uses ds-lite dhcpv6
extensions, which is not correct.
Consider the case where a MAP deployment has a need (for whatever reason)
to direct some CPEs to an AFTR (stateful NAT). Instead of rolling out
Ds-lite DHCP extensions all over, it is trivially simple to achieve the
desired effect with the above MAP CE behaviour in place.
This does not mean that those who want to use DS-lite dhcp extensions
cannot do so, if available. But it does mean that those who deploy MAP,
don't have to take care of mandating ds-lite dhcp extensions "just in case"
all over the shop.
As such, the functionality is IMO useful, and almost trivial to achieve in
an implementation.

-Wojciech.

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

---

From: Xing Li <[email-masked]>
Date: Fri, 22 Nov 2013 21:46:23 +0800

Wojciech Dec 写道:
>
>
>
> On 20 November 2013 20:54, Simon Perreault 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     WG,
>
>     In view of the recent discussions on provisioning, this
>     functionality strikes me as useless. There would be no reason for
>     an ISP to use such provisioning. A unified CPE would just do
>     DS-Lite if that's what's available.
>
> You seem to equate ds-lite to being only there if it uses ds-lite 
> dhcpv6 extensions, which is not correct.
> Consider the case where a MAP deployment has a need (for whatever 
> reason) to direct some CPEs to an AFTR (stateful NAT). Instead of 
> rolling out Ds-lite DHCP extensions all over, it is trivially simple 
> to achieve the desired effect with the above MAP CE behaviour in place.
> cannot do so, if available. But it does mean that those who deploy 
> MAP, don't have to take care of mandating ds-lite dhcp extensions 
> "just in case" all over the shop.
> As such, the functionality is IMO useful, and almost trivial to 
> achieve in an implementation.

Agree with Woj and an exmaple is demostrated in Section 4.1 of 
http://www.ietf.org/id/draft-xli-softwire-map-testing-02.txt

Regards,

xing

>     [email-masked] <mailto:[email-masked]>
> ------------------------------------------------------------------------
>

---

From: Simon Perreault <[email-masked]>
Date: Fri, 22 Nov 2013 09:39:04 -0500

Le 2013-11-22 05:30, Wojciech Dec a écrit :
> rolling out Ds-lite DHCP extensions all over

...or only to the CPEs in question...

> it is trivially simple to
> achieve the desired effect with the above MAP CE behaviour in place.
> don't have to take care of mandating ds-lite dhcp extensions "just in
> case" all over the shop.

s/all over the shop/to the CPEs in question/

Even if there is any efficiency gain over just sending the DHCPv6 
option, it must be so small that I don't think we should standardize 
this hack. When we can, we need to focus on one way of doing things. 
DHCP is well understood and liked by operators.

It's fine if you implement the hack, but there's no need for it in the RFC.

Simon

---

From: Wojciech Dec <[email-masked]>
Date: Fri, 22 Nov 2013 18:02:55 +0100

This is hardly a hack, it's a functional requirement of a CPE, specifying
how the CPE behaves with a case of NOT having an IPv4 address = no NAT44,
in this case. It's not about overflow.

Besides that very obvious case to handle, I provided an explanation of the
value the described behaviour brings, which has also been demonstrated (per
Xing's mail). So far you have not substantiated what is the down-side of
having this functionality on a MAP CPE, other than considering it not
useful. Could you do that?

Re: your substitution: No, an SP can hardly predict which CPEs in question
need to have DS-Lite capabilities (as in support ds-lite options, et al)

On 22 November 2013 15:39, Simon Perreault <[email-masked]>wrote:

> Even if there is any efficiency gain over just sending the DHCPv6 option,
> it must be so small that I don't think we should standardize this hack.
> When we can, we need to focus on one way of doing things. DHCP is well
> understood and liked by operators.
>

---

From: Ole Troan <[email-masked]>
Date: Sat, 23 Nov 2013 19:13:17 +0100

> This is hardly a hack, it's a functional requirement of a CPE, specifying how the CPE behaves with a case of NOT having an IPv4 address = no NAT44, in this case. It's not about overflow.
> 
> Besides that very obvious case to handle, I provided an explanation of the value the described behaviour brings, which has also been demonstrated (per Xing's mail). So far you have not substantiated what is the down-side of having this functionality on a MAP CPE, other than considering it not useful. Could you do that?
> 
> Re: your substitution: No, an SP can hardly predict which CPEs in question need to have DS-Lite capabilities (as in support ds-lite options, et al)

to take the overflow case, then you'd still need to provision this as two MAP domains.
does it make much difference if you provision it as one MAP domain and one 6334 option?

I'm in favour of having these mechanisms as ships in the night.

given that we already have a way to provision DS-lite (6334), I wouldn't really be in favour of adding another one.
I think CPE implementors have enough combinations already. ;-)

cheers,
Ole

---

From: Wojciech Dec <[email-masked]>
Date: Mon, 25 Nov 2013 10:39:09 +0100

You're apparently missing some key points:

1.  It's a functional requirement of a CPE, specifying how the CPE behaves
with a case of NOT having an IPv4 address. What is the to be the bahviour
of a MAP CPE without one?
2.  This is NOT about configuring a ds-lite CPE

Throughout, its still not been answered what is the downside of having this
functionality of a *MAP CPE*?

On 23 November 2013 19:13, Ole Troan <[email-masked]> wrote:

> > This is hardly a hack, it's a functional requirement of a CPE,
> specifying how the CPE behaves with a case of NOT having an IPv4 address =
> no NAT44, in this case. It's not about overflow.
> >
> > Besides that very obvious case to handle, I provided an explanation of
> the value the described behaviour brings, which has also been demonstrated
> (per Xing's mail). So far you have not substantiated what is the down-side
> of having this functionality on a MAP CPE, other than considering it not
> > Re: your substitution: No, an SP can hardly predict which CPEs in
> question need to have DS-Lite capabilities (as in support ds-lite options,
> et al)
>
> given that we already have a way to provision DS-lite (6334), I wouldn't
> really be in favour of adding another one.

---

From: Ole Troan <[email-masked]>
Date: Mon, 25 Nov 2013 13:39:47 +0100

Wojciech,

> You're apparently missing some key points: 

that's not uncommon. ;-)

> 1.  It's a functional requirement of a CPE, specifying how the CPE behaves with a case of NOT having an IPv4 address. What is the to be the bahviour of a MAP CPE without one?

just like if it didn't get an IPv4 address on native Ethernet.

> 2.  This is NOT about configuring a ds-lite CPE

my understanding was that the CPE had to be provisioned for this mode,
possibly as a separate MAP domain. and that the BR must also act as a CGN.

> Throughout, its still not been answered what is the downside of having this functionality of a *MAP CPE*?

it adds yet another variant.
what's wrong with provisioning the DS-lite option when you want this behaviour?
or if you want overflow from MAP to DS-lite?

I don't get the benefit of what you are suggesting.

cheers,
Ole

---

From: Simon Perreault <[email-masked]>
Date: Mon, 25 Nov 2013 13:13:53 -0500

> this functionality of a *MAP CPE*?

We've been told many times that operators don't want a zillion different 
ways of doing the same thing. This WG in particular has often been the 
target of such comments. We need to do something about it. IMHO this is 
one instance of duplication that can easily be eliminated.

Simon

---

From: Wojciech Dec <[email-masked]>
Date: Wed, 27 Nov 2013 20:37:32 +0100

On 25 November 2013 19:13, Simon Perreault <[email-masked]>wrote:

> target of such comments. We need to do something about it. IMHO this is one
> instance of duplication that can easily be eliminated.
>

How is describing the behaviour of a MAP CPE that has the IPv6 address of a
BR, but not an IPv4 address the duplication of anything?
Could you perhaps also stick to non-rhetorical answers.

Wojciech.

---

From: Wojciech Dec <[email-masked]>
Date: Wed, 27 Nov 2013 21:10:38 +0100

Now, how about this to move things forward: We replace the quoted
text/section with the following added into section 5.4

"A MAP-E CE provisioned with only the IPv6 address of the BR MUST
   disable its NAT44 functionality and treat the point-point tunnel
interface as active for IPv4 forwarding."

In case we want to proceed with the argument, it is continued inline...

On 25 November 2013 13:39, Ole Troan <[email-masked]> wrote:

> > 1.  It's a functional requirement of a CPE, specifying how the CPE
> behaves with a case of NOT having an IPv4 address. What is the to be the
> bahviour of a MAP CPE without one?
>

Now, the way MAP's forwarding rules have been modelled, the IPv4 default
route follows the IPv6 BR address. Hence, the presence of the IPv6 address
equates to the presence of a v4 default route, accessible via the tunnel to
the BR. In none of the v4 auto tunneling technology in use here is it a
requirement for the tunneling router to have some operator assigned IPv4
address on an interface to be able to forward packets on it.

> possibly as a separate MAP domain. and that the BR must also act as a CGN.

One doesn't need a DS-Lite CPE to be able to send IPv4inIPv6.

> what's wrong with provisioning the DS-lite option when you want this

Is DS-Lite required to configure a MAP CPE, or to enable IPv4inIPv6 on a
router?

> or if you want overflow from MAP to DS-lite?

I didn't bring up overflow - not sure why you added it.

> I don't get the benefit of what you are suggesting.

Clearly, but there are multiple as mentioned (not least, the ability for
the operator to actually turn off NAT44  on the user's CPE for t'shooting
purposes).

Cheers,
Wojciech.