Subject: FW:New Version Notification for draft-jiang-v6ops-incremental-cgn

From: Sheng Jiang <[email-masked]>
Date: Thu, 14 May 2009 08:44:17 +0800

Dear all,

A revised version of draft-jiang-v6ops-incremental-cgn has been submitted to
v6ops WG. It had been represented by Brian Carpenter in v6ops meeting in
IETF 74 as draft-jiang-incremental-cgn-00 and received positive comments
also modification comments. We have integrated these comments into this
version.

Please review and comments on it. Many thanks.

Best regards,

Sheng
 
> Filename:	   draft-jiang-v6ops-incremental-cgn
> Version:	   00
> Staging URL:	   
> http://tools.ietf.org/id/draft-jiang-v6ops-incremental-cgn-00.txt
> 
> Title:		   An Incremental Carrier-Grade NAT 
> (CGN) for IPv6 Transition
> Creation_date:	   2009-05-08
> WG ID:		   Indvidual Submission
> Number_of_pages: 11
> Abstract:
> Global IPv6 deployment was slower than originally expected in 
> the last ten years. As IPv4 address exhaustion gets closer, 
> the IPv4/IPv6 transition issues become more critical and 
> complicated. Host-based transition mechanisms are not able to 
> meet the requirements while most end users are not 
> sufficiently expert to configure or maintain these transition 
> mechanisms. Carrier Grade NAT with integrated transition 
> mechanisms can simplify the operation of end users during the 
> IPv4/IPv6 migration or coexistence period. This document 
> proposes an incremental Carrier-Grade NAT (CGN) solution for 
> IPv6 transition. 
> It can provide IPv6 access services for IPv6-enabled end hosts and
> IPv4 access services for IPv4 end hosts while remaining most 
> of legacy IPv4 ISP networks unchanged. It is suitable for the 
> initial stage of IPv4/IPv6 migration. Unlike CGN alone, it 
> also supports and encourages transition towards dual-stack or 
> IPv6-only ISP networks.
> 
> Submitter: Sheng Jiang ([email-masked])
> 
> Author(s):
> Sheng Jiang, [email-masked]
> Dayong Guo, [email-masked]
> Brian Carpenter, [email-masked]
> 
> 
> Comment:
> Replacement for draft-jiang-incremental-cgn-00
> 
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 14 May 2009 08:17:50 -0700

Dear authors,

The document is clean and concise, which is appreciated.
However, section 3.2 seems to be showing preference
toward a particular tunneling technology, and I'd like
to understand that better.

To understand this, we must first observe that the 6rd
approach relies on anycast for CPE router accessing of
IPv6 routers within the IPv4 ISP network. The idea of
anycast was entertained and abandoned by the ISATAP
team in the 2001/2002 timeframe when ISATAP was still
being developed in the ngtrans working group. This came
after much discussion among authors and guidance from
the working group. Reasons include:

1) if the tunnel fragments, fragments of the same packet
   may go to different anycast-addressed routers.

2) with anycast, there is no opportunity for default
   router selection (when there are multiple)

3) with anycast, there is no opportunity for traffic
   engineering

4) with anycast, IPv6 neighbor discovery over the
   tunnel may yield unpredictable results

5) with anycast, there is need for a manual provisioning
   of IPv6 prefixes and IPv4 anycast address on the CPE
   router.

We next observe that the 6rd mechanism is rooted in a
customized IPv6 prefix configuration that embeds an
IPv4 address. First, this would require that a quite
large IPv6 prefix (e.g., a /24) be delegated to the
ISP were its customers to obtain even a /56 as the
largest possible prefix. Such a prefix would be used
only sparsely, as only a small portion of the IPv4
address space may be available for assignment to CPE
routers. Secondly, the only mode of operation afforded
is Provider-Aggregated, i.e., there is no provision for
CPE use of Provider-Independent prefixes.

I suspect you know where I'm going with this, but take
each of the deficiencies named above and apply VET, and
you will see that VET robustly covers all of these cases
and more. Indeed, with VET as the phase 1 deployment,
there would be no need for a phase 2, and no need for
any IPv6 readdressing as VET uses unmodified IPv6
prefixes natively.

The VET model asks only that CPE routers become VET
enterprise border routers, that CGNs become VET
enterprise border gateways, and that the ISP name
service be provisioned with resource records for
border gateway discovery. In other words, the VET
deployment touches exactly the same CPE/PE equipment
that the 6rd approach touches, and VET asks only that
the ISP network administrators add a few resource
records to the DNS. If there are doubts as to how
VET satisfies each of these use cases, I will be
happy to explain in follow-up.

In your section 3.6, we note a strong recommendation
for a tunnel MTU of at least 1500 bytes and I concur
with this recommendation. Were that not the case,
customer devices would be constantly inconvenienced
with excessive ICMP PTB messages reporting degenerate
MTUs for crossing the ISP network. We also note that
SEAL uniquely and correctly provides the tunnel 1500
MTU assurance that incremental cgn is seeking, and
moreover note that larger MTUs (e.g., 9K) are robustly
and naturally discovered when customer devices request
them. Please see also RANGER Scenarios (RANGERS) for
additional insight into the application of VET and
SEAL into the ISP network problem space:

http://tools.ietf.org/html/draft-russert-rangers
http://tools.ietf.org/html/draft-templin-autoconf-dhcp
http://tools.ietf.org/html/draft-templin-seal

Fred
[email-masked] 

> -----Original Message-----
> From: Sheng Jiang [mailto:[email-masked]]
> Sent: Wednesday, May 13, 2009 5:44 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: FW:New Version Notification for
draft-jiang-v6ops-incremental-cgn

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 15 May 2009 10:00:06 +1200

Fred,

Regards
   Brian Carpenter
   University of Auckland

>    tunnel may yield unpredictable results

When I look at the 6rd draft, I don't really see why the relay needs
to be anycast - as far as I can see it could be genuinely unicast
(since there is no semantic difference for the CPE or the relay;
it's only anycast if the ISP sets up its IGP to make it anycast).
So the real question is how the CPE knows the 6rd relay address,
which is also a question for RFC3056. There are of course many
possible answers to that, e.g. a DHCP(v4) option.

Personally I think a provisioned unicast address may be better,
because of your points 1-4.
>    of IPv6 prefixes and IPv4 anycast address on the CPE

Which IPv6 prefixes? The CPE builds its IPv6 prefix from its
external IPv4 address, which it gets in the traditional way.

> routers. 

Yes. Are we running out of /24s yet?

> Secondly, the only mode of operation afforded

Yes. I would expect this method to be used for SOHO subscribers,
not for larger customers who might use PI.

> happy to explain in follow-up.

I don't see this for SOHO subscribers using $50 CPEs,
frankly, but I could be wrong.

     Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 15 May 2009 10:50:28 +1200

Fred,

(My previous message was somewhat inscrutable. See in-line.)

Thanks

     Brian

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 14 May 2009 16:02:04 -0700

> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Thursday, May 14, 2009 3:50 PM
> To: Templin, Fred L
> Cc: Sheng Jiang; [email-masked]; [email-masked]; Fleischman, Eric; Russert, Steven W; Rémi
> Després
> Subject: Re: New Version Notification for draft-jiang-v6ops-incremental-cgn
> 
> Fred,
> 

ISATAP and VET already have answers for that ([RFC5214],
Sections 8.3.2 and 9). If 6rd wants to do the same thing,
it would just be re-inventing the wheel.
 
> because of your points 1-4.

Provisioned unicast addresses are already the subject
matter for ISATAP/VET Potential Router List (PRL)
initialization. Is a new spec needed?

> external IPv4 address, which it gets in the traditional way.

The CPE needs to learn the provider's IPv6 prefix reserved
for 6rd purposes. Unless there is some form of automated
discovery (e.g., PIOs in RAs), the IPv6 prefix would need
to be manually provisioned.

> Yes. Are we running out of /24s yet?

Are we running out of /24s? I really don't know. Do
I know waste when I see it? I think so.
 
> not for larger customers who might use PI.

But, do you know what the service model will look
like 5-10yrs down the line? (Maybe coexisting wireless
broadband and cable modem?) Do you even know what
a SOHO network will look like 5-10yrs down the line?
PI is as some point going to become attractive to
enterprises of any size - not necessarily just the
big ones. 

> frankly, but I could be wrong.

Let's just have an awareness about this up front. Then,
we will have to explain to the customers years down the
line why we copped out and gave them a moped when they
could have had a 'VET.

Fred

---

From: Sheng Jiang <[email-masked]>
Date: Fri, 15 May 2009 10:12:26 +0800

Fred,

Thanks for your comments.

Although I can agree on you the disadvantages of anycast, anycast has its
advantages and suitable scenarios, too. Furthermore, I don't think 6rd
depends on anycast. Remi may give us clarification.

However, our draft does no intend to make judge of 6rd, or other tunnel
techonogies. We actually would like to list serveral suitable tunnel
techonogies with brief introductions in order to complete our puzzle. As we
ready state in the draft, "ISATAP or VET are also be considered." Actually,
one thing we can do for next version is to expand this section a little bit,
to include brief introductions for Auto GRE, ISATAP and VET. However, we
also think 6rd is suitable and do not want to rule it out.

Best regards,

Sheng

> From: Templin, Fred L [mailto:[email-masked]] 
> Sent: Friday, May 15, 2009 7:02 AM
> To: Brian E Carpenter
> Cc: Sheng Jiang; [email-masked]; [email-masked]; 
> Fleischman, Eric; Russert, Steven W; Rémi Després
> Subject: RE: New Version Notification for 
> > Cc: Sheng Jiang; [email-masked]; [email-masked]; Fleischman, 
> > Eric; Russert, Steven W; Rémi Després
> > > However, section 3.2 seems to be showing preference toward a 
> > > particular tunneling technology, and I'd like to understand that 
> > > better.
> > >
> > > To understand this, we must first observe that the 6rd approach 
> > > relies on anycast for CPE router accessing of
> > > IPv6 routers within the IPv4 ISP network. The idea of anycast was 
> > > entertained and abandoned by the ISATAP team in the 2001/2002 
> > > timeframe when ISATAP was still being developed in the ngtrans 
> > > working group. This came after much discussion among authors and 
> > > guidance from the working group. Reasons include:
> > >
> > (since there is no semantic difference for the CPE or the 
> relay; it's 
> > only anycast if the ISP sets up its IGP to make it anycast).
> > So the real question is how the CPE knows the 6rd relay 
> address, which 
> > is also a question for RFC3056. There are of course many possible 
> > answers to that, e.g. a DHCP(v4) option.
> 
> Sections 8.3.2 and 9). If 6rd wants to do the same thing, it 
> would just be re-inventing the wheel.
>  
> Provisioned unicast addresses are already the subject matter 
> for ISATAP/VET Potential Router List (PRL) initialization. Is 
> a new spec needed?
> 
> > Which IPv6 prefixes? The CPE builds its IPv6 prefix from 
> its external 
> > IPv4 address, which it gets in the traditional way.
> 
> discovery (e.g., PIOs in RAs), the IPv6 prefix would need to 
> be manually provisioned.
> 
> > > We next observe that the 6rd mechanism is rooted in a customized 
> > > IPv6 prefix configuration that embeds an
> > > IPv4 address. First, this would require that a quite large IPv6 
> > > prefix (e.g., a /24) be delegated to the ISP were its 
> customers to 
> > > obtain even a /56 as the largest possible prefix. Such a prefix 
> > > would be used only sparsely, as only a small portion of the IPv4 
> > > address space may be available for assignment to CPE routers.
> > 
> Are we running out of /24s? I really don't know. Do I know 
> waste when I see it? I think so.
>  
> > > Secondly, the only mode of operation afforded is 
> > > Provider-Aggregated, i.e., there is no provision for CPE use of 
> > > Provider-Independent prefixes.
> > 
> > Yes. I would expect this method to be used for SOHO 
> subscribers, not 
> > for larger customers who might use PI.
> 
> But, do you know what the service model will look like 
> 5-10yrs down the line? (Maybe coexisting wireless broadband 
> and cable modem?) Do you even know what a SOHO network will 
> look like 5-10yrs down the line?
> PI is as some point going to become attractive to enterprises 
> of any size - not necessarily just the big ones. 
> 
> each of the 
> > > deficiencies named above and apply VET, and you will see that VET 
> > > robustly covers all of these cases and more. Indeed, with 
> VET as the 
> > > phase 1 deployment, there would be no need for a phase 2, and no 
> > > need for any IPv6 readdressing as VET uses unmodified 
> IPv6 prefixes 
> > > natively.
> > >
> > > The VET model asks only that CPE routers become VET enterprise 
> > > border routers, that CGNs become VET enterprise border 
> gateways, and 
> > > that the ISP name service be provisioned with resource 
> records for 
> deployment touches 
> > > exactly the same CPE/PE equipment that the 6rd approach 
> touches, and 
> > > VET asks only that the ISP network administrators add a 
> few resource 
> > > records to the DNS. If there are doubts as to how VET 
> satisfies each 
> > > of these use cases, I will be happy to explain in follow-up.
> > 
> Let's just have an awareness about this up front. Then, we 
> will have to explain to the customers years down the line why 
> we copped out and gave them a moped when they could have had a 'VET.
> 
> Fred
> > > In your section 3.6, we note a strong recommendation for a tunnel 
> > > MTU of at least 1500 bytes and I concur with this recommendation. 
> > > Were that not the case, customer devices would be constantly 
> > > inconvenienced with excessive ICMP PTB messages reporting 
> degenerate 
> > > MTUs for crossing the ISP network. We also note that SEAL 
> uniquely 
> > > and correctly provides the tunnel 1500 MTU assurance that 
> > > incremental cgn is seeking, and moreover note that larger MTUs 
> > > (e.g., 9K) are robustly and naturally discovered when customer 
> > > devices request them. Please see also RANGER Scenarios 
> (RANGERS) for 
> > > additional insight into the application of VET and SEAL 
> into the ISP 
> > > network problem space:
> > >
> > >> v6ops WG. It had been represented by Brian Carpenter in v6ops 
> > >> meeting
> > > in
> > >> also modification comments. We have integrated these 
> comments into
> > > this
> > >> version.
> > >>
> > >>> Global IPv6 deployment was slower than originally 
> expected in the 
> > >>> last ten years. As IPv4 address exhaustion gets closer, the 
> > >>> IPv4/IPv6 transition issues become more critical and 
> complicated. 
> > >>> Host-based transition mechanisms are not able to meet the 
> > >>> requirements while most end users are not sufficiently 
> expert to 
> > >>> configure or maintain these transition mechanisms. 
> Carrier Grade 
> > >>> NAT with integrated transition mechanisms can simplify the 
> > >>> operation of end users during the
> > >>> IPv4/IPv6 migration or coexistence period. This 
> document proposes 
> > >>> an incremental Carrier-Grade NAT (CGN) solution for
> > >>> IPv6 transition.
> > >>> IPv4 access services for IPv4 end hosts while remaining most of 
> > >>> legacy IPv4 ISP networks unchanged. It is suitable for 
> the initial 
> > >>> stage of IPv4/IPv6 migration. Unlike CGN alone, it also 
> supports 
> > >>> and encourages transition towards dual-stack or IPv6-only ISP 
> > >>> networks.
> > >>>
> > >>> Sheng Jiang, [email-masked] Dayong Guo, 
> [email-masked]

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 15 May 2009 05:17:54 -0700

Hi Sheng,

> Sent: Thursday, May 14, 2009 7:12 PM
> To: Templin, Fred L; 'Brian E Carpenter'
> Cc: [email-masked]; [email-masked]; Fleischman, Eric; Russert, Steven W; 'Rémi Després'
> Subject: RE: New Version Notification for draft-jiang-v6ops-incremental-cgn
> 
> Fred,
> 

As near as I can tell, the contribution of 6rd is the
definition of a "stateless" prefix delegation mechanism;
everything else is just intra-site tunneling, and 6rd
would do well to look at the ISATAP/VET mechanisms that
already handle this.

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 15 May 2009 12:36:12 -0700

> From: Templin, Fred L
> Sent: Friday, May 15, 2009 5:18 AM
> To: Sheng Jiang; Brian E Carpenter
> Cc: [email-masked]; [email-masked]; Fleischman, Eric; Russert, Steven W; Rémi Després

With this said, I'd like to propose something toward Remi.
You will be wanting some way for CPE devices to discover
the ISP's 6rd-relays IPv6 prefix. This can be easily
accommodated by defining a new DHCPv6 option (the
"6rd Prefix Option"?) for which the sole purpose is
to convey a prefix and prefix length.

The CPE device can then use Stateless DHCPv6 to obtain
the prefix from a relay/server in the ISP network via
IPv6/IPv4 tunneling. The address of the relay/server
can be discovered using the PRL discovery mechanisms
of ISATAP [RFC5214].

Thanks - Fred

---

From: Rémi Després <[email-masked]>
Date: Tue, 19 May 2009 11:18:35 +0200

> to understand that better.

As explained in the 6rd draft (soon to become an RFC), 6rd solves the 
major problem of 6to4: the lack of guarantee that paths exist between 
all IPv6 sites and all 6to4 sites, and that these paths have ISP 
controlled QoS.

> IPv6 routers within the IPv4 ISP network.

The important point is that the 6rd-relay address MAY be anycast. If 
there is only one relay at this address, there is no difference with an 
anycast address.
Reasons for permitting  anycast are SCALABILITY and AVAILABILITY of the 
solution:
- if available relays seem to be soon insufficient for the traffic, just 
add one more, at the same anycast address. While ISATAP is intra-site, 
6rd relays, like those of 6to4 which also use an anycast address, have 
to support all the IPv6 traffic of an ISP that uses 6rd.
- if a 6rd-relay fails, the traffic goes to another one.

  The idea of
>    may go to different anycast-addressed routers.

If the ISP supports an IPv4 MTU long enough for IPv6 packets of 1280 
octets (as it should) and discards longer ones, no fragmentation is ever 
needed.
This is common with 6to4, which uses anycast addressing for its relays.

>    router selection (when there are multiple)

Yes. But what is the practical problem?

> 3) with anycast, there is no opportunity for traffic

Different source zones may be oriented toward different relays, or relay 
farms with internal load balancers.

All the complexity of deciding which customer sites should receive which 
unicast addresses is avoided.

>    tunnel may yield unpredictable results

Neighbor discovery doesn't apply more over 6rd tunnels than it does on 
6to4 tunnels.

>    of IPv6 prefixes and IPv4 anycast address on the CPE

As explained in the draft, Free deployed 6rd with their 6rd parameters 
included in their downloaded CPE software (IPv6 prefix and relay anycast 
address).

For independently supplied CPEs , tools to convey these parameters have 
to be specified. As far as I know, Mark Townsley is working on a 
proposal for this.

Regards,

RD

---

From: Rémi Després <[email-masked]>
Date: Tue, 19 May 2009 11:29:50 +0200

> also think 6rd is suitable and do not want to rule it out.

Yes.

As far as I know, among ISATAP, VET, and 6rd,  the latter is the only 
one to have been actually deployed on a large scale, offering native 
IPv6 to millions of customer sites. It deserves IMHO to be understood as 
such.

More details in:
http://rosie.ripe.net/ripe/meetings/ripe-58/presentations/uploads//presentations/Tuesday/Plenary%2011:00/Cassen-IPv6_at_Free.wWE6.pdf

Best regards,

RD

---

From: Rémi Després <[email-masked]>
Date: Tue, 19 May 2009 11:45:04 +0200

> to convey a prefix and prefix length.

There is indeed a need.

Note that it should rather be a *DHCPv4* option, since it is needed 
before there is IPv6 connectivity.

As mentioned in another email, and as far as I know, Mark Townsley is 
working on it.

I believe it should be quickly agreed on, to expand applicability of a 
useful tool for rapid deployment of native IPv6.

Regards,

RD

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 19 May 2009 07:29:57 -0700

Remi,

> From: Rémi Després [mailto:[email-masked]]
> Sent: Tuesday, May 19, 2009 2:19 AM
> To: Templin, Fred L
> Cc: Sheng Jiang; [email-masked]; [email-masked]; [email-masked]; Fleischman,
> Eric; Russert, Steven W

Yes, so is VET soon to become an RFC. But, 6rd is not solving a
6to4 problem with its open relays; it is solving an intra-site
problem with ordinary IPv6 routers just like VET.
 
> Reasons for permitting  anycast are SCALABILITY and AVAILABILITY of the

Just for the record, ISATAP/VET can use anycast just
the same as for 6rd but chose not to specify it. This
choice was based on deliberations between authors and
working group alike that identified the stated problems.

> - if a 6rd-relay fails, the traffic goes to another one.

No; 6rd is intra-site. The site is the ISP operator's
network.

> This is common with 6to4, which uses anycast addressing for its relays.

1280 is an unsatisfactory MTU for customer devices that
would prefer to use 1500. The CPE is an in-the-network
tunnel endpoint such that customer devices on a 1500
segment would be constantly inconvenienced with ICMP
PTB messages were the CPE to deploy with only 1280.

But, if you want to push the CPE tunnel endpoint to
1500, you have to allow for the possibility of
fragmentation. VET and SEAL solve this problem.

> Yes. But what is the practical problem?

If there are multiple PE routers in the ISP network,
the CPE should have the ability to distinguish them
and choose between them - just as for any link where
there may be multiple routers.

> farms with internal load balancers.

Traffic engineering is the ability for a CPE router
to direct some traffic through PE router A and other
traffic through PE router B. With anycast, the CPE
router can't discern A from B.

> unicast addresses is avoided.

I don't see anything having to do with complexity, really.
And, it's the very same consideration as to which customers
should receive which DNS suffixes.

> Neighbor discovery doesn't apply more over 6rd tunnels than it does on

Neighbor discovery is useful in many ways. NUD, default
router preferences and more specific routes, SEND, and
many more. 6rd is not really comparable to 6to4, however;
6rd is intra-site just as ISATAP/VET.

> included in their downloaded CPE software (IPv6 prefix and relay anycast

This is unnecessarily marrying the CPE devices to the
ISP in a way that CPE vendors might not appreciate. It
also makes renumbering and discovery of new prefixes
quite cumbersome.
 
> to be specified. As far as I know, Mark Townsley is working on a

If Mark Townsley is working on a proposal for this, he is
re-inventing ISATAP PRL discovery. See also my proposal
for stateless DHCP prefix delegation for the 6rd prefix.

Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 19 May 2009 07:29:59 -0700

> Sent: Tuesday, May 19, 2009 2:30 AM
> To: Sheng Jiang
> Cc: Templin, Fred L; 'Brian E Carpenter'; [email-masked]; [email-masked]; Fleischman, Eric;
> Russert, Steven W

Hmm, ISATAP is in all of our Windows PCs right now and
has been for years. Various other proprietary and public
domain implementations support it as well. Various sites
use it, but its hard to know which ones because it all
just looks like IPv6 when it comes out of the site. I
hear that it is used fairly extensively in China, and
also in large corporate enterprise networks.

Fred

> More details in:
> http://rosie.ripe.net/ripe/meetings/ripe-
> 58/presentations/uploads//presentations/Tuesday/Plenary%2011:00/Cassen-IPv6_at_Free.wWE6.pdf
> 
> Best regards,
> 
> RD

---

From: Rémi Després <[email-masked]>
Date: Tue, 19 May 2009 16:56:59 +0200

> also in large corporate enterprise networks.

Fair enough.

My remark applied ONLY to ISPs that offer native IPv6 to their customer 
sites across  IPv4 ISP infrastructures, not to private sites.

Regards,

RD

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 19 May 2009 08:19:15 -0700

Remi,

(resend - sorry, my fingers slipped on the first try...)

> Sent: Tuesday, May 19, 2009 2:45 AM
> To: Templin, Fred L
> Cc: Sheng Jiang; Brian E Carpenter; [email-masked]; [email-masked]; Fleischman, Eric; Russert,
> Steven W

Not if there is link-local IPv6 capability as ISATAP/VET
have. With link-local IPv6, DHCPv6 gives the natural
alternative for obtaining stateless information like
6rd prefix and stateful information like *real* IPv6
prefixes. I believe many customers would prefer the
latter.
 
> useful tool for rapid deployment of native IPv6.

Native IPv6 is not necessary with a solid VET deployment.
With VET, you deploy it once and leave it. With 6rd, you
deploy twice - once for the initial 6rd deployment and
again when the ISP has (unnecessarily) converted all of
its routers and networks to IPv6.

Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 19 May 2009 07:29:59 -0700

Remi,

 
> As mentioned in another email, and as far as I know, Mark Townsley is

Mark has been consistently pushing back on and delaying
my work - in a blocking fashion. Maybe this is why.

Fred

---

From: Gert Doering <[email-masked]>
Date: Tue, 19 May 2009 21:24:30 +0200

Hi,

> Native IPv6 is not necessary with a solid VET deployment.

I can't follow that line of reasoning.  The end result has to be an
IPv6-only network, not something held together with IPv4 clutches.

Native IPv6 without IPv4 is the only sustainable solution in the long run.

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  128645

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 19 May 2009 15:09:39 -0700

> From: Gert Doering [mailto:[email-masked]]
> Sent: Tuesday, May 19, 2009 12:25 PM
> To: Templin, Fred L
> Cc: Rémi Després; Sheng Jiang; Brian E Carpenter; [email-masked]; [email-masked]; Fleischman,
> Eric; Russert, Steven W

IMHO, native IPv6 in edge networks is desirable and natural,
where the edge networks may be as simple as a singleton node
and its attached devices. What we are talking about here is
VET deployment of IPv6 over IPv4 networks, but it is not
"held together" with IPv4. It is instead held together with
IPv6 routing and addressing.

> Native IPv6 without IPv4 is the only sustainable solution in the long run.

This strikes me as a matter of opinion, and does not
mesh well with use cases and deployment scenarios we
are seeing. See RANGER(S):

http://tools.ietf.org/html/draft-russert-rangers
http://tools.ietf.org/html/draft-templin-ranger

Fred

---

From: Gert Doering <[email-masked]>
Date: Wed, 20 May 2009 08:29:16 +0200

Hi,

On Tue, May 19, 2009 at 03:44:30PM -0700, Fleischman, Eric wrote:
> Your position below is very familiar to me since it was the same
> position that the UN and world's governments took about OSI. By
> contrast, I state that there is a strong motivation by the end user
> to use IPv4 indefinitely until a compelling reason to migrate to
> IPv6 arises.

As soon as a certain critical amount of networks and network traffic 
are using IPv6, maintaining IPv4 is extra cost with doubtful benefit.  

This alone is a reason to abandon IPv4.

I'm not talking about "this year", but about a few years in the future.

> At this current time, IPv6 is very immature and IPv6 deployments
> have very high risk when compared to IPv4 for the end user. There
> are only negative business reasons for deploying IPv6 at this time
> (i.e., I can articulate many compelling business reasons to NOT
> deploy IPv6 but the only reason to deploy it in the USA today is
> government decree -- which didn't work for OSI and is unlikely to
> work alone by itself for IPv6.). There are currently no technical
> reasons for the end user to prefer or want IPv6 over IPv4.

"End users" don't want IPv4 either.  They want web, mail, skype, bittorrent.

There already are large IPv6 deployments (free.fr has active IPv6 customers
in the order of a million users, if I remember the numbers right).  Other
big telcos are working on rolling out IPv6 to their DSL customer base - and
as soon as that happens, you have IPv6 users.  They wouldn't know, of course,
but that doesn't matter.

(Of course this is a europe-centric view.  IPv6 is happening here :) ).

Gert Doering
        -- NetMaster

---

From: JiangSheng 66104 <[email-masked]>
Date: Wed, 20 May 2009 14:48:04 +0800

> end users view networks as a business overhead expense and are 
> unlikely to needlessly spend money on networking technology 
> without a solid business motivation to do so. I went on to explain 
> that IPng is unlikely to be deployed by us end users unless it 
> becomes bundled with a business requirement, the most compelling 
> of which would be a new Killer Application that demanded IPv6 
> capabilities in order to function.

Fully agreed. This is particularly true for IPv6 deployment in last ten year - failure to find a killer application. A right business model is actually more important than technology itself.

> reasons for the end user to prefer or want IPv6 over IPv4. 

I believe this situation is changed. IPv4 has reached its limitation. End-user will soon find that they could NOT obtain a public IPv4 address and with private IPv4 address (maybe more than one NAT in the way) they were only able to communicate with part of Internet world. ISP has met the problem that they cannot adopt new services due to the lack of public address.
 
> Unless this changes in the future, IPv6 will continue to not be 
> deployed by end users despite the efforts of Apple and Microsoft 
> and others to ease its adoption. But then, since not all ISPs 
> support IPv6 today and the DFZ Internet is currently unprepared 
> for the BGP scaling problems that would arise with a mixed IPv4-
> IPv6 infrastructure this is probably A Good Thing.

This is a real issue which has been ignored by IPv6 community for years. My guess is IPv6 community does not want to discuss this because it may even more block IPv6 deployment. However, it is time for us to face it and solve it or avaoid it.
 
> I personally *HOPE* that IPv6 will become deployed -- after all, I 
> spent many years helping to create it. But my experience with pre-
> TCP/IP protocols (I used to be an SNA and BSC "expert") is that 
> even if IPv6 becomes widely deployed, IPv4 will endure for a 
> surprisingly long time (decades). 

Yes, it will be years. I believe the whole internet society has accepted this and be prepared for a 25+ year co-existing period.

Best regards,

Sheng
 
> I have many conflicting visions of what this could mean. Back in 
> 1999 Tony Li privately explained to me how IPv4 could endure 
> forever with no IPv6 ever being deployed. Tony's insights are 
> commonplace today as evidenced by the combination of NATs, private 
> addresses, and VPNs. I admit that as a possibility but I hope that 
> it doesn't happen. I prefer for IPv6 to gradually become deployed 
> and replace IPv4. However, my clear preference is for the 
> flexibility of the RANGER solution. The RANGER solution creates an 
> interworking environment so that it interworking occurs no matter 
> what the transport is at any part of the Internet -- the network 
> can cleanly support IPv4 only, IPv6 only, or IPv4-IPv6 all mixed 
> together. Such flexibility is a powerful tool for handling 
> whatever vision we may have for the future of networking.
> 
> --Eric Fleischman
> 
> Cc: Rémi Després; Sheng Jiang; Brian E Carpenter; 
> [email-masked]; [email-masked]; Fleischman, Eric; Russert, 
> Steven W
> > > I believe it should be quickly agreed on, to expand 
> applicability of 
> > > a useful tool for rapid deployment of native IPv6.
> > 
> I can't follow that line of reasoning.  The end result has to be 
> an IPv6-only network, not something held together with IPv4 clutches.
> 
> Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-
> CulemannD-80807 Muenchen                   HRB: 136055 (AG Muenchen)

---

From: Mohacsi Janos <[email-masked]>
Date: Wed, 20 May 2009 09:52:56 +0200 (CEST)

On Wed, 20 May 2009, JiangSheng 66104 wrote:

> Fully agreed. This is particularly true for IPv6 deployment in last ten 
> year - failure to find a killer application. A right business model is 
> actually more important than technology itself.

Solid business motivation - your providers wants to increase the service 
provisioning fee since they have to pay for the public IP address

Killer aplication - Internet Protocol (with version independent 
applications)

> This is a real issue which has been ignored by IPv6 community for years. 
> My guess is IPv6 community does not want to discuss this because it may 
> even more block IPv6 deployment. However, it is time for us to face it 
> and solve it or avaoid it.

According to our findings in our IPv6 deployment:
- deploying IPv6 on backbone network is easy and relatively painless
- deploying IPv6 on access network is not obvious, but can be done in 
scalable way
- deploying IPv6 at customers is very painful - very conservative 
application owners are hindering of introducing IPv6 even when their 
application cannot support it....

- deploying IPv6 at home has showstoppers: no IPv6 capable CPE under 100 
USD. After introducing such a device - at least 10 years is necessary to 
the users to replace older devices.....

> Yes, it will be years. I believe the whole internet society has accepted 
> this and be prepared for a 25+ year co-existing period.

Agreed.

Best Regards,
 		Janos Mohacsi

---

From: Seiichi Kawamura <[email-masked]>
Date: Wed, 20 May 2009 17:00:00 +0900

Hi

A document such as this is very helpful and I thank the authors.
One concern I have about this kind of model is the widespread
ICMP filtering in IPv4 networks. I see many ISPs that filter ICMPv6
just as they do with IPv4 and has been causing problmes. This
is especially important in a tunnel based solution such as this.

> This alone is a reason to abandon IPv4.

IMHO, maintaining a fully dual stacked
network is very expensive. How expensive? would depend
on the size of your network, or what equipment you are using,
or what kind of services you provide, but some day when
IPv6 does spread, the "extra cost" will need to be charged
to customers and that's probably when we may start to see a
motivation by the end users.

As far as my network goes, configurations are 1.5 times
longer, maintenance time is slightly longer, and all automation
and management tools need be developed and maintained to
support both stacks.

Regards,
Seiichi Kawamura

---

From: Rémi Després <[email-masked]>
Date: Wed, 20 May 2009 10:19:57 +0200

> the users to replace older devices.....

I suggest a look at draft-despres-6rd-03 (soon to become an 
informational RFC).
Thanks to the 6rd idea, Free, the second largest Internet provider in 
France with millions of residential customers, has offered IPv6 to its 
home sites at no extra charge since December 2007.
I use IPv6 on a regular basis for Google access, GoogleMap, document 
access on IETF servers etc.

In my understanding, BitTorrent on Free's network works better in IPv6 
than in IPv4 because hosts can receive incoming calls without 
limitations caused by IPv4 NATs.

>> Yes, it will be years. I believe the whole internet society has 
>> accepted this and be prepared for a 25+ year co-existing period.

Coexistence is fine provided plain IPv6 is made rapidly available. IPv4 
should be used less and less as more and more hosts have IPv6 access.

Regards,

RD

---

From: Mohacsi Janos <[email-masked]>
Date: Wed, 20 May 2009 11:05:05 +0200 (CEST)

On Wed, 20 May 2009, Rémi Després wrote:

> I suggest a look at draft-despres-6rd-03 (soon to become an informational 
> RFC).
> Thanks to the 6rd idea, Free, the second largest Internet provider in France 
> with millions of residential customers, has offered IPv6 to its home sites at 
> no extra charge since December 2007.
> I use IPv6 on a regular basis for Google access, GoogleMap, document access 
> on IETF servers etc.
>
> In my understanding, BitTorrent on Free's network works better in IPv6 than 
> in IPv4 because hosts can receive incoming calls without limitations caused 
> by IPv4 NATs.

I very much aware 6rd solution - we discussed it on the IETF 72. The most 
important drawbacks:
- requires providider control over the CPE devices.

It could be improved the 6rd prefix made available via some method (.e.g 
DHCP) for generic CPE devices + persuade CPE vendors to implement this 
solution

Best Regards,
 		Janos Mohacsi

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 20 May 2009 11:10:41 +0200

Actually we have done real deployments with only-IPv6 in some networks that
have a majority of IPv6 traffic already and we have been able to disable
IPv6 in the core and access, keeping private IPv4 with NAT+global IPv6
addresses in the LANs and data center, then an IPv4-to-IPv6 proxy to access
the rest of Internet, some other tricks to automatically tunnel IPv4-in-IPv6
(from the LANs to the Internet-border) in order to avoid using NAT-PT and
still being able to use ALL the rest of IPv4 applications in Internet.

So it is a real case from years, in some cases.

Regards,
Jordi

> From: Gert Doering <[email-masked]>
> Reply-To: <[email-masked]>
> Date: Wed, 20 May 2009 08:29:16 +0200
> To: "Fleischman, Eric" <[email-masked]>
> Cc: Gert Doering <[email-masked]>, "Templin, Fred L"
> <[email-masked]>, Rémi Després <[email-masked]>, Sheng Jiang
> <[email-masked]>, Brian E Carpenter <[email-masked]>,
> <[email-masked]>, <[email-masked]>, "Russert, Steven W"
> <[email-masked]>

**********************************************
The IPv6 Portal: http://www.ipv6tf.org

Bye 6Bone. Hi, IPv6 !
http://www.ipv6day.org

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: JiangSheng 66104 <[email-masked]>
Date: Wed, 20 May 2009 17:25:01 +0800

> is especially important in a tunnel based solution such as this.

Hi, Seiichi, thanks for your reply. I understand your concern. Yes, ICMP fliter is a problem. We will take this in count later.

> and management tools need be developed and maintained to

Fully agreed. Actually, I am very much concern about this. Many ISPs seem have accepted the concept of dual-stack network with really understanding the complication and costs of it. I guess we need to do something to expose this. Otherwise, the whole industry may be misleaded.

Best regards,

Sheng

> Regards,
> Seiichi Kawamura
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (MingW32)
> 
> iD8DBQFKE7iAcrhTYfxyMkIRAku/AJ40myWRtgLVNTR+5xvwxxLkM/+mfQCffjHT
> CyppSE6gXszqiEtNbOrqED8=
> =CiGi
> -----END PGP SIGNATURE-----
>

---

From: JiangSheng 66104 <[email-masked]>
Date: Wed, 20 May 2009 16:46:46 +0800

Hi, Mohacsi,

I think we are talking about the same: IPv6 itself is a killer application and will be deployed globally through there will be many years for co-existing.

You mentioned deploying IPv6 is easy or with little problem. I agree.

However, the issues I meant is problems for IPv6/IPv4 mext infrastracture or call dual-stack network. It increases the complicity a lot. As Eric said, the DFZ Internet is currently unprepared for the BGP scaling problems that would arise with a mixed IPv4-IPv6 infrastructure.

Best regards,

Sheng

----- Original Message -----
From: Mohacsi Janos <[email-masked]>
Date: Wednesday, May 20, 2009 3:55 pm
Subject: Re: RE: New Version Notification for draft-jiang-v6ops-incremental-cgn
To: JiangSheng 66104 <[email-masked]>
Cc: "Fleischman, Eric" <[email-masked]>, Gert Doering <[email-masked]>, "Templin, Fred L" <[email-masked]>,Rémi Després <[email-masked]>, Brian E Carpenter <[email-masked]>, [email-masked], [email-masked], "Russert, Steven W" <[email-masked]>

> accepted

---

From: Rémi Després <[email-masked]>
Date: Wed, 20 May 2009 11:48:12 +0200

Mohacsi Janos  -  le (m/j/a) 5/20/09 11:05 AM:
>>> - deploying IPv6 at home has showstoppers: no IPv6 capable CPE under 
>>> 100 USD. After introducing such a device - at least 10 years is 
>>> necessary to the users to replace older devices.....
>>
> I very much aware 6rd solution - we discussed it on the IETF 72. The 
> most important drawbacks:

True (but more a provisional limitation than drawback.

> DHCP) for generic CPE devices + persuade CPE vendors to implement this 

Absolutely.

I participated in private discussions in this direction in San Francisco 
in March. As far as I know, Mark Townsley is planning to submit a draft 
to this effect.

Best regards,

RD

---

From: Mark Townsley <[email-masked]>
Date: Wed, 20 May 2009 15:17:27 +0200

Indeed, 6rd is targeted to ISPs who have the ability to specify the 
residential gateway's functionality. This certainly does not apply to 
all ISP offerings, but it does apply to quite a few.

As Remi points out, he and I (and others) have been working together 
recently on a new 6rd spec which includes some of the things discussed 
here (DHCP options, etc). Current plan is to have that out in the next 
week or so.

- Mark

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 20 May 2009 06:37:41 -0700

Mark,

> From: Mark Townsley [mailto:[email-masked]]
> Sent: Wednesday, May 20, 2009 6:17 AM
> To: Templin, Fred L
> Cc: Rémi Després; Sheng Jiang; [email-masked]; [email-masked]; [email-masked];
> Fleischman, Eric; Russert, Steven W

I must apologize to you and to the list for inappropriate
non-technical content directed toward you in an earlier
message. That said, I believe the following technical
content merits consideration.

For the 6rd prefix discovery, what you are suggesting is
simply a stateless IPv6 prefix delegation. It is stateless
in the sense that the customer need only discover the
operator's /32 or larger prefix, and then the customer
can self-assign its own IPv6 prefix based on its IPv4
address. This can be done as a DHCPv4 option, or if
link-local IPv6 is available it can also be done as a
DHCPv6 option. But, stateless IPv6 prefix delegation
is really what it is.

For 6rd router unicast/anycast address discovery, that
function would be identical to the potential router list
(PRL) discovery mechanisms of ISATAP/VET. Indeed, 6rd is
nothing more than ISATAP/VET with many of the features
removed. A worthwhile idea to consider is to combine
the 6rd stateless prefix delegation (which AFAICT is
its primary contribution) with the already defined
mechanisms of ISATAP and VET.

Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 20 May 2009 07:06:29 -0700

The two technical points to address are:

- we will want to get IPv6 all the way to the end users
- what is the operator's cost for maintaing both IPv4
  and IPv6

VET (vis-à-vis RANGER) is all about getting IPv6 all the
way to the end users. When operators deploy IPv6 border
gateways in their networks, and when customers convert
their CPE devices to IPv6, the IPv6 service will reach
all the way in to the end users.

The operator can get its network up to IPv6 by deploying
only a few IPv6-capable border gateways and leave the
rest of its IPv4 network intact. This would be no different
than having the operator deploy a few extra servers.
Indeed, there would actually be a large cost with no
clear benefits for the operator to decommission its
already existing IPv4 deployment.

VET/ISATAP is a deploy-once-and-be-done solution.

VET/ISATAP/6rd would be too, albeit with an IPv6
prefix that exposes the end user's IPv4 address
(which may be private) to the outside world.

VET/ISATAP/SEAL would further solve the problem
of ICMP filtering and assure a robust path MTU to
the end user.

Fred

> Sent: Tuesday, May 19, 2009 11:29 PM
> To: Fleischman, Eric
> Cc: Gert Doering; Templin, Fred L; Rémi Després; Sheng Jiang; Brian E Carpenter; [email-masked];
> [email-masked]; Russert, Steven W

---

From: Mohacsi Janos <[email-masked]>
Date: Wed, 20 May 2009 16:25:39 +0200 (CEST)

Janos Mohacsi
Network Engineer, Research Associate, Head of Network Planning and Projects
NIIF/HUNGARNET, HUNGARY
Key 70EF9882: DEC2 C685 1ED4 C95A 145F  4300 6F64 7B00 70EF 9882

On Wed, 20 May 2009, JiangSheng 66104 wrote:

> Hi, Seiichi, thanks for your reply. I understand your concern. Yes, ICMP 
> fliter is a problem. We will take this in count later.

They should have a look at this draft:

http://tools.ietf.org/html/rfc4890

Best Regards,
 	Janos Mohacsi

---

From: Mark Townsley <[email-masked]>
Date: Wed, 20 May 2009 16:35:40 +0200

> content merits consideration.
No problem.
> address.
Yes, that's a significant part of it.
>  This can be done as a DHCPv4 option,
Yes.
>  or if
> is really what it is

The transition mechanism is targeted to provide IPv6 to a residential 
internet user over an access network that is currently only able to 
provide IPv4. If the RG has any IPv6 address on its SP-facing interface, 
and DHCPv6 is deployed in the SP network, then the SP is probably well 
on its way to not needing 6rd anyway.
> removed. 
Everything under the sun has already been invented. I think of 6rd as 
more a modification to 6to4, but I suppose it depends on your perspective.
> A worthwhile idea to consider is to combine
On the face of it, I fail to see what that would provide given what 6rd 
sets out to achieve. Perhaps we can better have this discussion once the 
-00 is available though.

- Mark

---

From: JiangSheng 66104 <[email-masked]>
Date: Fri, 22 May 2009 02:08:46 +0800

Hi, Fleischman,

We all work hard to contribute the fast change Internet world. Althrough we may have different opinions from time to time, our ultimate goals are the same, I believe.

I will read and comment on RANGER.

Best regards,

Sheng

----- Original Message -----
From: "Fleischman, Eric" <[email-masked]>
Date: Wednesday, May 20, 2009 11:51 pm
Subject: RE: RE: New Version Notification for draft-jiang-v6ops-incremental-cgn
To: JiangSheng 66104 <[email-masked]>
Cc: Gert Doering <[email-masked]>, "Templin, Fred L" <[email-masked]>,Rémi Després <[email-masked]>, Brian E Carpenter <[email-masked]>, [email-masked], [email-masked], "Russert, Steven W" <[email-masked]>

> Sheng,
> 
> I'm glad that our views are congruent. I believe that our shared 
> viewpoint is a reasonable one though I recognize that other 
> vectors are also possible.
> 
> I apologize for my previous long posting. In hindsight, I wish 
> that I had solely stated that because the Internet is likely to 
> face a period of accelerated change in the next few years, with 
> accompanying challenges within the network operations domain, it 
> behooves us to adopt techniques that will help our community 
> weather these anticipated events.
> 
> This is the reason why I personally have been encouraging 
> coworkers to consider RANGER because I believe that it has 
> preserved the original intent of the founders of the Internet in a 
> manner that would enable today's Internet to flourish and evolve 
> during the difficult challenges ahead.
> 
> I would appreciate it if you all would please read and consider 
> RANGER and the new RANGERS I-D and share your insights on those 
> concepts. A strength of our community is the quality of our 
> technical discussions together. 
> 
> Best wishes,
> 
> --Eric Fleischman
> 
> From: JiangSheng 66104 [mailto:[email-masked]] 
> Sent: Tuesday, May 19, 2009 11:48 PM
> To: Fleischman, Eric
> Cc: Gert Doering; Templin, Fred L; Rémi Després; Brian E 
> Carpenter; [email-masked]; [email-masked]; Russert, Steven 
> W; [email-masked]
> without a 
> > solid business motivation to do so. I went on to explain that 
> IPng is 
> > unlikely to be deployed by us end users unless it becomes 
> bundled with 
> > a business requirement, the most compelling of which would be a 
> new 
> > Killer Application that demanded IPv6 capabilities in order to 
> > function.
> 
> Fully agreed. This is particularly true for IPv6 deployment in 
> last ten year - failure to find a killer application. A right 
> business model is actually more important than technology itself.
> 
> have 
> > very high risk when compared to IPv4 for the end user. There are 
> only 
> > negative business reasons for deploying IPv6 at this time (i.e., 
> I can 
> > articulate many compelling business reasons to NOT deploy IPv6 
> but the 
> > only reason to deploy it in the USA today is government decree --
> 
> > which didn't work for OSI and is unlikely to work alone by 
> itself for 
> > IPv6.). There are currently no technical reasons for the end 
> user to 
> > prefer or want IPv6 over IPv4.
> 
> I believe this situation is changed. IPv4 has reached its 
> limitation. End-user will soon find that they could NOT obtain a 
> public IPv4 address and with private IPv4 address (maybe more than 
> one NAT in the way) they were only able to communicate with part 
> of Internet world. ISP has met the problem that they cannot adopt 
> new services due to the lack of public address.
> 
> and 
> > others to ease its adoption. But then, since not all ISPs 
> support IPv6 
> > today and the DFZ Internet is currently unprepared for the BGP 
> scaling 
> > problems that would arise with a mixed IPv4-
> This is a real issue which has been ignored by IPv6 community for 
> years. My guess is IPv6 community does not want to discuss this 
> because it may even more block IPv6 deployment. However, it is 
> time for us to face it and solve it or avaoid it.
> 
> even 
> > if IPv6 becomes widely deployed, IPv4 will endure for a 
> surprisingly 
> > long time (decades).
>