Subject: [v6ops] I-D Action:draft-ietf-v6ops-incremental-cgn-02.txt

From: [email-masked]
Date: Sun, 10 Oct 2010 19:15:02 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Operations Working Group of the IETF.

	Title           : An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition
	Author(s)       : S. Jiang, D. Guo
	Filename        : draft-ietf-v6ops-incremental-cgn-02.txt
	Pages           : 13
	Date            : 2010-10-10

Global IPv6 deployment was slower than originally expected. As IPv4 
address exhaustion approaches, the IPv4 to IPv6 transition issues 
become more critical and less tractable. Host-based transition 

 mechanisms used in dual stack environments are not able to meet the 
transition requirements. Most end users are not sufficiently expert 
to configure or maintain host-based transition mechanisms. Carrier-
Grade NAT (CGN) devices with integrated transition mechanisms can 
reduce the operational change required during the IPv4 to IPv6 
migration or coexistence period. 

This document proposes an incremental CGN approach for IPv6 
transition. It can provide IPv6 access services for IPv6-enabled 
hosts and IPv4 access services for IPv4 hosts while leaving much of a 
legacy IPv4 ISP network unchanged. It is suitable for the initial 
stage of IPv4 to IPv6 migration. Unlike NAT444 based CGN alone, 
Incremental CGN also supports and encourages transition towards dual-
stack or IPv6-only ISP networks. A smooth transition to IPv6 
deployment is also described in this document. 

An integrated configurable CGN device and an adaptive Home Gateway 
(HG) device are introduced. Both HG and CGN are re-usable devices 
during different transition periods. It avoids potential multiple 
upgrades. It enables IPv6 migration to be incrementally achieved 
according to the real user requirements.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-incremental-cgn-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Rémi Després <[email-masked]>
Date: Mon, 11 Oct 2010 09:42:02 +0200

Hi Sheng, Diang, Brian,

The draft says 
"[ISPs]... currently face two urgent pressures - to compensate for an immediate shortage of IPv4 addresses by deploying some method of address sharing, and to prepare actively for the use of deployment of IPv6 address space and services. ISPs facing only one pressure out of   two could adopt either CGN (for shortage of IPv6 addresses) or 6rd."

This misses the point that 6rd can also be used by ISPs that, to face the IPv4 address shortage, operate CGN44s and assign private IPv4 addresses to their customers.
This is illustrated in particular in section 4 of RFC 5569:
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
              ______________________________
             |                              |
             | 10.x.x.x/8 private addresses |
             |  <==                         |
       <-----|         IPv4 anycast address |----->
             |            of 6rd relays     |
    6rd-CPEs |                      ==>     |  6rd-relays
             |                              |
       <-----|          0.0.0.0/0           |----->
             |              :               |
             |______________V_______________|
                          __|__
    ISP-supported NAT(s) |     |
                         |_____|
                            |
                            V
                 IPv4 public addresses
          Figure 3: 6rd Applicability to ISPs That Assign
                    IPv4 Private Addresses
If a home gateway supports 6rd with the DHCPv4 option introduced in RFC 5969, the goal of incremental CGN seems to be reached with already specified mechanisms.

Thoughts?

Regards,
RD 

> <Pièce jointe Mail>_______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Sheng Jiang <[email-masked]>
Date: Mon, 11 Oct 2010 15:58:22 +0800

Hi, Remi,

You are right here. You may notice, incremental cgn is an information document, which does not
define any concrete mechanisms. It gives guidelines and discuss time sequence and steps during
transitioning. 6rd with private Ipv4 addresses is one of concrete instance of the certain phase of
incremental cgn. We have already indicated this. Both RFC5569, RFC5969 are quoted in the document.

Best regards,

Sheng

> -----Original Message-----
> From: Rémi Després [mailto:[email-masked]] 
> Sent: Monday, October 11, 2010 3:42 PM
> To: Sheng Jiang; Diang Guo; Brian Carpenter
> Cc: v6ops v6ops
> Subject: Re: [v6ops] I-D 
> Action:draft-ietf-v6ops-incremental-cgn-02.txt
> 
> Hi Sheng, Diang, Brian,
> 
> The draft says 
> "[ISPs]... currently face two urgent pressures - to 
> compensate for an immediate shortage of IPv4 addresses by 
> deploying some method of address sharing, and to prepare 
> actively for the use of deployment of IPv6 address space and 
> services. ISPs facing only one pressure out of   two could 
> adopt either CGN (for shortage of IPv6 addresses) or 6rd."
> 
> This misses the point that 6rd can also be used by ISPs that, 
> to face the IPv4 address shortage, operate CGN44s and assign 
> private IPv4 addresses to their customers.
> If a home gateway supports 6rd with the DHCPv4 option 
> introduced in RFC 5969, the goal of incremental CGN seems to 
> be reached with already specified mechanisms.
> 
> Thoughts?
> 
> Regards,
> RD 
> 
> 
> 
> > transition requirements. Most end users are not 
> sufficiently expert to 
> > configure or maintain host-based transition mechanisms. 
> Carrier- Grade 
> > NAT (CGN) devices with integrated transition mechanisms can 
> reduce the 
> > operational change required during the IPv4 to IPv6 migration or 
> > coexistence period.
> > 
> > transition. It can provide IPv6 access services for 
> IPv6-enabled hosts 
> > and IPv4 access services for IPv4 hosts while leaving much 
> of a legacy 
> > IPv4 ISP network unchanged. It is suitable for the initial stage of 
> > IPv4 to IPv6 migration. Unlike NAT444 based CGN alone, 
> Incremental CGN 
> > also supports and encourages transition towards dual- stack or 
> > IPv6-only ISP networks. A smooth transition to IPv6 
> deployment is also

---

From: Rémi Després <[email-masked]>
Date: Mon, 11 Oct 2010 10:38:59 +0200

Thanks Sheng for the quick answer.

Yet, in the sentence I quoted, the draft suggests that 6rd is not a solution to face both pressures (1. to compensate for an immediate shortage of IPv4 addresses by deploying some method of address sharing; 2.  to prepare actively for the use of deployment of IPv6 address space and services). 

It can be confusing, I believe, for network operators, mobiles operators in particular, that have already deployed CGN44s.
For them, 6rd can be the only additional solution they need to address both pressures. 

If the draft can clarify how 6rd and CGN44s can be used jointly to address both pressures, without needing any new design, it will IMHO serve a very useful purpose in v6ops. 

But, then, the term "Incremental CGN" remains confusing IMHO 
CGN44+6rd, or something similar, could be an intuitive name for the solution.

Regards,
RD

---

From: <[email-masked]>
Date: Mon, 11 Oct 2010 14:04:16 +0200

Dear Rémi;

I don't understand well here the underlying rationale to offer v6 over v4 behind a CGN and then to claim this is to "prepare actively for the use of deployment of IPv6".

If you share the public IP address, you loose one the important aspects of 6rd: having a global (IPv6) address and therefore to ease inbound connections.

IMHO, if we want to encourage the deployment of IPv6, we need to focus on native deployment and stop with these v6 in v4 tunnelling proposals. 

Having these proposals about tunnelling over IPv4 is another hurdle we have within our organisation to promote native IPv6 deployment.

Cheers,
Med 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Rémi Després
Envoyé : lundi 11 octobre 2010 10:39
À : Sheng Jiang
Cc : 'v6ops v6ops'
Objet : Re: [v6ops] I-D Action:draft-ietf-v6ops-incremental-cgn-02.txt

Regards,
RD

>> This is illustrated in particular in section 4 of RFC 5569:

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

*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************

---

From: Rémi Després <[email-masked]>
Date: Mon, 11 Oct 2010 14:47:46 +0200

Hi Med,

> I don't understand well here the underlying rationale to offer v6 over v4 behind a CGN and then to claim this is to "prepare actively for the use of deployment of IPv6".

In my understanding, rapidly providing native IPv6 addresses to hosts leads them to use more and more IPv6, and less and less IPv4.
It does increases IPv6 use AND deployment (not sure about use OF deployment).
What is important IMHO is services users get, not underlying mechanics used to provide them.

> If you share the public IP address, you loose one the important aspects of 6rd: having a global (IPv6) address and therefore to ease inbound connections.

There must be a confusion here.
In the CGN44+6rd solution: 
- IPv6 addresses aren't shared
- Private IPv4 addresses from which they are derived aren't shared either (at least where they apply, i.e. in networks behind CGNs).

> IMHO, if we want to encourage the deployment of IPv6, we need to focus on native deployment and stop with these v6 in v4 tunnelling proposals. 

Note that I am not making any new tunneling proposal here.
I just point out that 6rd is a solution that, combined with CGN44s, permits ISPs that have to share IPv4 addresses and want to offer IPv6 service to do it without having to switch to dual-stack routing or Ipv6-only routing now.

> Having these proposals about tunnelling over IPv4 is another hurdle we have within our organisation to promote native IPv6 deployment.

Your organization is obliged in any way to adopt choices that, in view of their own constraints, some others find good for them.

Now, if you implicitly talk about 6a44, which is indeed a new tunneling mechanism, this isn't a discussion for this thread.
(It has no relationship with incremental CGN or  CGN44+6rd.)
Its purpose is easy deployment of native IPv6 across legacy IPv4-only CPEs, a need of many users that want reliable IPv6 connectivity where CPEs can't be changed in the short term.

Regards,
RD

---

From: Randy Bush <[email-masked]>
Date: Mon, 11 Oct 2010 21:55:17 +0900

> I don't understand well here the underlying rationale to offer v6 over
> v4 behind a CGN and then to claim this is to "prepare actively for the
> use of deployment of IPv6".

maybe if you dring another 500ml of the cgn koolaid the visions will
come to you.

randy

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 12 Oct 2010 10:30:45 +1300

Med,

On 2010-10-12 01:04, [email-masked] wrote:
...
> IMHO, if we want to encourage the deployment of IPv6, we need to focus on native deployment and stop with these v6 in v4 tunnelling proposals. 

Personally, I agree with you (and Randy). But some operators don't agree
with you, are firmly engaged in the CGN direction, and want guidance on how
to proceed. Just saying "don't" will not help anybody.

    Brian

---

From: Randy Bush <[email-masked]>
Date: Tue, 12 Oct 2010 07:41:34 +0900

>> IMHO, if we want to encourage the deployment of IPv6, we need to
>> focus on native deployment and stop with these v6 in v4 tunnelling
>> proposals.
> Personally, I agree with you (and Randy). But some operators don't
> agree with you, are firmly engaged in the CGN direction, and want
> guidance on how to proceed. Just saying "don't" will not help anybody.

yes.  i love when my competition is foolish.

but the question is why should we, as the v6ops wg, consider the cgn
part to be v6 deployment?  it is actually tortured v4 deployment.

does it require different tools than punching v6 through any other
entrenched v4 network?  for example, as med pointed out, 6rd and the
other hacks will work.

randy

---

From: "Yiu L. Lee" <[email-masked]>
Date: Mon, 11 Oct 2010 21:16:31 -0400

Hi Remi,

> - Private IPv4 addresses from which they are derived aren't shared either (at
> least where they apply, i.e. in networks behind CGNs).
> 
This is true only if there is no overlapped private space. If an overlapped
space is used, a different 6rd domain should be used.

Cheers,
Yiu

---

From: Sheng Jiang <[email-masked]>
Date: Tue, 12 Oct 2010 09:33:27 +0800

Hi, Remi,

The WGLC on this draft was just ended Sep 23. The 02 version was produced to integrate all the
comments we received during the WGLC. It is now submitted for IESG evaluation. We are now waiting
for AD comments, and when we get those we can consider additional changes. We think our draft
already does explain how CGN and 6rd are complementary.

Regards,

Sheng

> Sent: Monday, October 11, 2010 4:39 PM
> To: Sheng Jiang
> Cc: 'Diang Guo'; 'Brian Carpenter'; 'v6ops v6ops'
> Subject: Re: [v6ops] I-D 
> Yet, in the sentence I quoted, the draft suggests that 6rd is 
> not a solution to face both pressures (1. to compensate for 
> an immediate shortage of IPv4 addresses by deploying some 
> method of address sharing; 2.  to prepare actively for the 
> use of deployment of IPv6 address space and services). 
> 
> It can be confusing, I believe, for network operators, 
> mobiles operators in particular, that have already deployed CGN44s.
> If the draft can clarify how 6rd and CGN44s can be used 
> jointly to address both pressures, without needing any new 
> design, it will IMHO serve a very useful purpose in v6ops. 
> 
> > You are right here. You may notice, incremental cgn is an 
> information 
> > document, which does not define any concrete mechanisms. It gives 
> > guidelines and discuss time sequence and steps during 
> transitioning. 
> > 6rd with private Ipv4 addresses is one of concrete instance 
> of the certain phase of incremental cgn. We have already 
> indicated this. Both RFC5569, RFC5969 are quoted in the document.
> > 
> > Best regards,
> > 
> > Sheng
> > 
> compensate for an 
> >> immediate shortage of IPv4 addresses by deploying some method of 
> >> address sharing, and to prepare actively for the use of 
> deployment of 
> >> IPv6 address space and
> >> This misses the point that 6rd can also be used by ISPs 
> that, to face 
> >> the IPv4 address shortage, operate CGN44s and assign private IPv4 
> >> addresses to their customers.
> introduced in 
> >> RFC 5969, the goal of incremental CGN seems to be reached with 
> >> already specified mechanisms.
> >> 
> >> Thoughts?
> >> 
> >> Regards,
> >> RD
> >> 
> >> 
> >> 
> http://www.ietf.org/internet-drafts/draft-ietf-v6ops-incremental-cgn-
> >> 0
> >>> 2.txt
> >>>

---

From: Rémi Després <[email-masked]>
Date: Tue, 12 Oct 2010 08:08:42 +0200

> space is used, a different 6rd domain should be used.

Agreed.
That's what I meant.

Cheers,
RD

---

From: <[email-masked]>
Date: Tue, 12 Oct 2010 08:27:50 +0200

Dear Rémi,

I'm not referring to 6a44 but to the IPv6 over IPv4 in a NAT444 model you are proposing. 

Cheers,
Med 

-----Message d'origine-----
De : Rémi Després [mailto:[email-masked]] 
Envoyé : lundi 11 octobre 2010 14:48
À : BOUCADAIR Mohamed NCPI/NAD/TIP
Cc : Sheng Jiang; 'v6ops v6ops'; BINET David NCPI/NAD/TIP
Objet : Re: [v6ops] I-D Action:draft-ietf-v6ops-incremental-cgn-02.txt

Hi Med,

Regards,
RD

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 13 Oct 2010 10:59:14 +1300

> part to be v6 deployment?  it is actually tortured v4 deployment.

Well, this gets back to whether coexistence techniques are part of
the v6ops charter, and I understood the conclusion to be yes.
That still doesn't mean that we have to like the technique.

> entrenched v4 network?  for example, as med pointed out, 6rd and the

Yes. Various tunneling techniques would work. The document lists
several of them in section 2.2.

   Brian

---

From: Randy Bush <[email-masked]>
Date: Wed, 13 Oct 2010 07:03:30 +0300

> the v6ops charter, and I understood the conclusion to be yes.

ships in the night != coexistence

randy

---

From: Fred Baker <[email-masked]>
Date: Tue, 12 Oct 2010 21:30:57 -0700

> ships in the night != coexistence

If everyone does a dual stack deployment, you have ships in the night. Is everyone doing a dual stack deployment? Sounds like not necessarily.

---

From: Randy Bush <[email-masked]>
Date: Wed, 13 Oct 2010 08:20:04 +0300

> If everyone does a dual stack deployment, you have ships in the night.

and we don't need a wg document for it, do we?

> Is everyone doing a dual stack deployment? Sounds like not
> necessarily.

no.  cernet2, for example, does v6 only.  others do v4 only.  neither
needs a major wg effort, documents, ...

some do v4 only but provide v6 tunneling crutches (6rd).  6rd documents
how to do that.  same for the other tunnels.

randy

---

From: Joel Jaeggli <[email-masked]>
Date: Tue, 12 Oct 2010 23:10:42 -0700

> and we don't need a wg document for it, do we?

nope, but ops people may find a reason to milk along or hop over their
broken v4 access network for the time being. doing it long term seems
like a fools errand. It doesn't seem especially onerous to document what
that might look like if if some of the participants have to hold their
noses.

Ultimately, I belive that mucking about with v4cgn, or indeed v4 a+p is
going to leave one at a competitive disadvantage those those that either
choose not to, or don't have to. That's a problem that will probably
sort itself out,because you can quite easily make your service both
crappier and more expensive by heading in that direction...

> no.  cernet2, for example, does v6 only.  others do v4 only.
> neither needs a major wg effort, documents, ...
> 
> some do v4 only but provide v6 tunneling crutches (6rd).  6rd
> documents how to do that.  same for the other tunnels.
> 
> randy _______________________________________________ v6ops mailing
> list [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Randy Bush <[email-masked]>
Date: Wed, 13 Oct 2010 09:21:15 +0300

> that might look like if if some of the participants have to hold their

and i said

>> documents how to do that.  same for the other tunnels.

i.e. the hopping mechanism document how to deal with ipv4 or broken ipv4
networks.

randy

---

From: Joel Jaeggli <[email-masked]>
Date: Tue, 12 Oct 2010 23:39:53 -0700

Joel's widget number 2

> i.e. the hopping mechanism document how to deal with ipv4 or broken ipv4

I'm inclined to conclude that 6rd is a tool not the tool. The broken v4 network is still there in your 6rd deployment, in fact it's a precondition.

---

From: Randy Bush <[email-masked]>
Date: Wed, 13 Oct 2010 09:42:25 +0300

>> i.e. the hopping mechanism document how to deal with ipv4 or broken
>> ipv4 networks.
> I'm inclined to conclude that 6rd is a tool not the tool. The broken
> v4 network is still there in your 6rd deployment, in fact it's a
> precondition.

yes.  and each tool documents how it punches through v4.

are you advocating that the nat docs should each tell how each and every
tool should be configured to punch it?

randy

---

From: Rémi Després <[email-masked]>
Date: Wed, 13 Oct 2010 09:08:26 +0200

> tool should be configured to punch it?

Just to make sure no readers are confused: 6rd is NOT a NAT punching tool.
NAT docs need not to be concerned.

6rd is just a tool to rapidly offer native IPv6 service to some users.
With it, hosts cannot know that part of the traversed network wasn't directly routing IPv6.

RD

---

From: Joel Jaeggli <[email-masked]>
Date: Wed, 13 Oct 2010 00:18:23 -0700

Joel's widget number 2

> tool should be configured to punch it?

No, I would be satisfied with characterizing the level of harm a particular approach inflicts.

---

From: Randy Bush <[email-masked]>
Date: Wed, 13 Oct 2010 10:24:29 +0300

> particular approach inflicts.

then we're on the same page.  a cgn doc should warn of any issues it
creates in both v4 and v6.  and this is what i thought behave was
supposed to be doing.

randy

---

From: Tim Chown <[email-masked]>
Date: Wed, 13 Oct 2010 10:40:15 +0100

> If everyone does a dual stack deployment, you have ships in the night. Is everyone doing a dual stack deployment? Sounds like not necessarily.

Having run a dual-stack site for a few years, yes the network perspective may be ships in the night, but really I don't want to manage two networks, I want to manage one.   Finding the tools that are aware of both protocols, and let you manage them in a consistent manner is, in my view, very important.    You might have separate IPv4 and IPv6 firewall appliances for example, but being able to apply a common implementation on policy across both, through a single interface/toolset, is highly desirable.

We're watching NAT64-style developments closely to determine when IPv6-only internally might be realistic.   At the moment dual-stack works for us, but I would imagine many greenfield networks will be pushing the NAT64 approach and we hope to learn from them.

Tim

---

From: Rémi Després <[email-masked]>
Date: Wed, 13 Oct 2010 14:44:45 +0200

Hi Tim,

On 13 oct. 2010 at 11:40, Tim Chown wrote:
> ...
> We're watching NAT64-style developments closely to determine when IPv6-only internally might be realistic.

You may also be interested in closely watching SAM/4rd.
It is a simplified alternative to NAT64, and to DS-lite, to maintain IPv4 connectivity across IPv6-only routing networks (including when  IPv4 addresses have to be shared among customer sites).
It can coexist with NAT64 and/or DS-lite if these solutions are previously deployed.

The current specification is tools.ietf.org/html/draft-despres-softwire-sam-01 - section 3.2.
I plan to have by Monday an updated draft whos title is "Global IPv4 Residual Deployment across IPv6 Networks (4rd) - a Stateless Solution";

Regards,
RD

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 14 Oct 2010 10:07:49 +1300

> creates in both v4 and v6.  and this is what i thought behave was

Our draft says:

"2.7. Discussion

   For IPv4 traffic, the incremental CGN approach inherits all the
   problems of CGN address sharing techniques
   [I-D.ietf-intarea-shared-addressing-issues] (e.g., scaling, and the
   difficulty of supporting well-known ports for inbound traffic).
   Application layer problems created by double NAT are for further
   study."

I tend to agree that expansion on this point belongs in BEHAVE.

     Brian