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

[Rémi Després <[e-mail]>]

Hi Med,

Le 11 oct. 2010 à 14:04, <[e-mail]> <[e-mail]> a écrit :

> 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".

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 
 
> 
> Cheers,
> Med 
> 
> -----Message d'origine-----
> De : [e-mail] [mailto:[e-mail]] 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
> 
> 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
> 
> 
> Le 11 oct. 2010 à 09:58, Sheng Jiang a écrit :
> 
>> 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:[e-mail]] 
>>> 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.
>>> 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 
>>> 
>>> 
>>> 
>>>> 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-0
>>>> 2.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.
>>>> <Pièce jointe Mail>_______________________________________________
>>>> v6ops mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/v6ops
>>> 
>>> 
>> 
> 
> 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> 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.
> ********************************
>