Subject: [v4tov6transition] Fwd: draft-arkko-ipv6-transition-guidelines WGLC

From: Fred Baker <[email-masked]>
Date: Mon, 16 Aug 2010 09:01:24 -0700

We have a transition guideline in last call in the IPv6 Operations Working Group. Let me take this opportunity to invite all of us to join [email-masked] if we have not, read the document, and comment on it on [email-masked] in the context of that last call.

http://tools.ietf.org/html/draft-arkko-ipv6-transition-guidelines
  "Guidelines for Using IPv6 Transition Mechanisms", Jari Arkko, Fred
  Baker, 12-Jul-10

I gather that the operators on this list are of the opinion that the documents on the table, which include that one and the documents it refers to - especially 

http://www.ietf.org/rfc/rfc4213.txt
4213 Basic Transition Mechanisms for IPv6 Hosts and Routers. E.
     Nordmark, R. Gilligan. October 2005. (Format: TXT=58575 bytes)
     (Obsoletes RFC2893) (Status: PROPOSED STANDARD)

but also various other RFCs and Internet Drafts - don't give them the guidance they are looking for. On this list, would it be appropriate to ask operators to tell us what questions remain on the table?

If, for example, operators are looking for a document that describes how to use IPv4/IPv4 NATs to extend the IPv4 domain while the deploy IPv6, so that their customers continue to have some level of IPv4 support during the transition, I wonder to what extent 

http://tools.ietf.org/html/draft-ietf-v6ops-incremental-cgn
  "An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition", Sheng
  Jiang, Dayong Guo, Brian Carpenter, 18-Jun-10

addresses their questions. I have scheduled it for IPv6 Operations Working Group last Call starting on the 12th of September, but would be happy to see comments on [email-masked] prior to that.

Begin forwarded message:

> From: Fred Baker <[email-masked]>
> Date: August 15, 2010 11:00:04 AM PDT
> To: [email-masked]
> Cc: [email-masked], [email-masked]
> Subject: draft-arkko-ipv6-transition-guidelines WGLC
> 
> This is to initiate a two week working group last call of draft-arkko-ipv6-transition-guidelines. Please read it now. If you find nits (spelling errors, minor suggested wording changes, etc), comment to the authors; if you find greater issues, such as disagreeing with a statement or finding additional issues that need to be addressed, please post your comments to the list.
> 
> We are looking specifically for comments on the importance of the document as well as its content. If you have read the document and believe it to be of operational utility, that is also an important comment to make.

---

From: Seiichi Kawamura <[email-masked]>
Date: Tue, 17 Aug 2010 13:49:54 +0900

Hi Fred

> but also various other RFCs and Internet Drafts - don't give them the guidance they are looking for. On this list, would it be appropriate to ask operators to tell us what questions remain on the t…

Here's my answer to this question.

Opertors who have not yet deployed IPv6,
don't know what to do at all. Some want
guidelines like, go and get a /32,
register it in an IRR (if they do so with IPv4),
check if your router supports IPv6, and if not
choose a transition deployment model, route
the prefix, buy transit, and finally bring some server up
so the world can see you that you have IPv6.
This is ISP 101 stuff that any operator should know,
but some request this kind of guidance.
I don't really see value in having a document
that describes all these steps.

However, many operators who have just started and have
at least some knowledge of what IPv6 is, want to know
traps in advance. This I think is quite important.
The differences between IPv4 and IPv6 that everyone stubles through.
I've been asked these same questions over and over again.

  How do you assign an address in your network?
   (recommended prefix length and value of interface ID)
  How do you use link-local?
  Is there RFC1918 space in IPv6?
  Is there such a thing as secondary address with IPv6?
  What's the BGP filtering boundary in IPv6 compimenting the /24 in IPv4?
  Is there a filtering guideline for IPv6?

Operators with more experience have more specific thoughts.

  Why does OSPFv3 not display global scope address associated with the interface?
  Why is VRRPv3's global VIP optional and not implemented by some?
  What FIB size should we expect with IPv6?
  Are broacasts with IPv4 and ND with IPv6 treated the same way in my L2 switch?
  How should be use rDNS with IPv6?

To summarize my long and rough comments (sorry)
"what is the difference between IPv6 and IPv4 that we should be aware of?"
is the question that many tend to ask and is always a popular topic
in my local NOG (JANOG).

Regards,
Seiichi

---

From: Tina TSOU <[email-masked]>
Date: Tue, 17 Aug 2010 15:12:05 +0800

It can also be part of the draft-lee-v4tov6transition-problem-statement, 
which we are working on.

B. R.
Tina
http://tinatsou.weebly.com/index.html
----- Original Message ----- 
From: "Fred Baker" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, August 17, 2010 2:59 PM
Subject: Re: draft-arkko-ipv6-transition-guidelines WGLC

Thanks very much, Kawmura-san. As you say, some of these questions are not 
worthy of an operator, but many are important to all of them. If we can get 
all of the questions on the table, I'm sure we can build a draft that we 
might call an "IPv6 Deployment FAQ". I wonder if you would be willing to 
co-author it with me?

On Aug 16, 2010, at 9:49 PM, Seiichi Kawamura wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Fred
>
> Fred Baker wrote:
>> We have a transition guideline in last call in the IPv6 Operations 
>> Working Group. Let me take this opportunity to invite all of us to join 
>> [email-masked] if we have not, read the document, and comment on it 
>> on [email-masked] in the context of that last call.
>>
>> I gather that the operators on this list are of the opinion that the 
>> documents on the table, which include that one and the documents it 
>> refers to - especially
>>
>> but also various other RFCs and Internet Drafts - don't give them the 
>> guidance they are looking for. On this list, would it be appropriate to 
>> ask operators to tell us what questions remain on the table?
>
>> If, for example, operators are looking for a document that describes how 
>> to use IPv4/IPv4 NATs to extend the IPv4 domain while the deploy IPv6, so 
>> that their customers continue to have some level of IPv4 support during 
>> the transition, I wonder to what extent
>>
>> addresses their questions. I have scheduled it for IPv6 Operations 
>> Working Group last Call starting on the 12th of September, but would be 
>> happy to see comments on [email-masked] prior to that.
>>
>> Begin forwarded message:
>>
>>> This is to initiate a two week working group last call of 
>>> draft-arkko-ipv6-transition-guidelines. Please read it now. If you find 
>>> nits (spelling errors, minor suggested wording changes, etc), comment to 
>>> the authors; if you find greater issues, such as disagreeing with a 
>>> statement or finding additional issues that need to be addressed, please 
>>> post your comments to the list.
>>>
>>> We are looking specifically for comments on the importance of the 
>>> document as well as its content. If you have read the document and 
>>> believe it to be of operational utility, that is also an important 
>>> comment to make.
>>
>>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
>
> iEYEARECAAYFAkxqFPIACgkQcrhTYfxyMkKR8ACeMWWs4R9yi1JO4VGrx5QrG0vV
> 1lwAn16RYKVoGzEw3zJc67IgdvBH/7t+
> =826C
> -----END PGP SIGNATURE-----

---

From: Tom Taylor <[email-masked]>
Date: Tue, 17 Aug 2010 10:20:47 -0400

Agreed, we shouldn't be fragmenting our efforts.

If that is acceptable to you, Kawamura-san?

Tina TSOU wrote:
> ----- Original Message ----- From: "Fred Baker" <[email-masked]>
> Thanks very much, Kawmura-san. As you say, some of these questions are 
> not worthy of an operator, but many are important to all of them. If we 
> can get all of the questions on the table, I'm sure we can build a draft 
> that we might call an "IPv6 Deployment FAQ". I wonder if you would be 
> willing to co-author it with me?
> 
>>> Working Group. Let me take this opportunity to invite all of us to 
>>> join [email-masked] if we have not, read the document, and 
>>> comment on it on [email-masked] in the context of that last call.
>>>
>>> guidance they are looking for. On this list, would it be appropriate 
>>> to ask operators to tell us what questions remain on the table?
>>
>>> If, for example, operators are looking for a document that describes 
>>> how to use IPv4/IPv4 NATs to extend the IPv4 domain while the deploy 
>>> IPv6, so that their customers continue to have some level of IPv4 
>>> support during the transition, I wonder to what extent
>>>
>>> Working Group last Call starting on the 12th of September, but would 
>>> be happy to see comments on [email-masked] prior to that.
>>>
>>> Begin forwarded message:
>>>
>>>> draft-arkko-ipv6-transition-guidelines. Please read it now. If you 
>>>> find nits (spelling errors, minor suggested wording changes, etc), 
>>>> comment to the authors; if you find greater issues, such as 
>>>> disagreeing with a statement or finding additional issues that need 
>>>> to be addressed, please post your comments to the list.
>>>>

---

From: "Yiu L. Lee" <[email-masked]>
Date: Tue, 17 Aug 2010 10:47:24 -0400

I also agree. Seiichi, would you mind I include your notes to the I-D?

Thanks,
Yiu

On 8/17/10 10:20 AM, "Tom Taylor" <[email-masked]> wrote:

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

---

From: Fred Baker <[email-masked]>
Date: Tue, 17 Aug 2010 13:51:43 -0700

Well, yes, but let me carefully comment here. A problem statement is a question; an FAQ is a set of answers. If the problem statement is "we have some basic questions and need some answers", OK, the FAQ is both question and answer. If the problem statement is something else - which I would expect the IESG to want it to be if they are going to allocate time for a BOF in Beijing - then an FAQ would be part of the response but not the entire response, and I would expect it to be separate from and responsive to the problem statement.

Since I haven't seen a draft of the problem statement, it's hard for me to assess that, and hard for me to contribute to the effort...

On Aug 17, 2010, at 12:12 AM, Tina TSOU wrote:

> It can also be part of the draft-lee-v4tov6transition-problem-statement, which we are working on.
> 
> 
> B. R.
> Tina
> Thanks very much, Kawmura-san. As you say, some of these questions are not worthy of an operator, but many are important to all of them. If we can get all of the questions on the table, I'm sure we can build a draft that we might call an "IPv6 Deployment FAQ". I wonder if you would be willing to co-author it with me?
>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 18 Aug 2010 10:08:18 +1200

> It can also be part of the draft-lee-v4tov6transition-problem-statement,

Just a suggestion, make it draft-lee-v4v6tran-problem-statement.
If you limit the tag to 8 characters it can also be a BOF name.

Another little team is working on draft-carpenter-v4v6tran-framework.

    Brian

---

From: Seiichi Kawamura <[email-masked]>
Date: Wed, 18 Aug 2010 08:52:48 +0900

Hi Yiu, Tom

(Replying to both mails at once)
I don't mind at all.
I haven't seen the problem statement draft
yet so I don't really have a clue if those sets of
specific questions are really relevant to a 'problem statement'.
I'll leave that decision up to you.

Regards,
Seiichi

---

From: "Yiu L. Lee" <[email-masked]>
Date: Tue, 17 Aug 2010 19:54:07 -0400

Hi Seiichi,

We are working on it now and will keep you posted.

Thanks,
Yiu

On 8/17/10 7:52 PM, "Seiichi Kawamura" <[email-masked]> wrote:

> iEYEARECAAYFAkxrIM8ACgkQcrhTYfxyMkLTXwCfQaGZUSH+VXxyCWabxcB4ub7/
> EgQAnixNumh30suuQorJt0eVZbIc6VLJ
> =0HRl

---

From: Tina TSOU <[email-masked]>
Date: Wed, 18 Aug 2010 09:09:39 +0800

Good suggestion.

All, should I incorporate [email-masked] directly into 
[email-masked]?

B. R.
Tina

---

From: "Yiu L. Lee" <[email-masked]>
Date: Tue, 17 Aug 2010 21:11:26 -0400

> [email-masked]?
I think we should.

Regards,
Yiu

---

From: Tina TSOU <[email-masked]>
Date: Wed, 18 Aug 2010 09:37:16 +0800

Fred,
You understood the procedures and how to make things easier much more than 
us. Brian does also. We see two IETF ex-chairs in this group. I'm so 
honoured working with you. I agree with you.

Now, the pieces come into a big picture.
- 1 doc: Problem Statement (Yiu et al are working on it.)
- multiple docs: Individual operator's use cases (Yiu, Can-Can, Lian-Yuan, 
Chris, Victor, Julien are working on them)
- 1 doc: v4 to v6 transition framework (Brian et al are working on it.)
- multiple docs: v4 to v6 transition steps/handbooks(should find a better 
wording, the answers of the FAQ is one of the inputs)

Just my 2 cents.

B. R.
Tina

----- Original Message ----- 
From: "Fred Baker" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, August 18, 2010 4:51 AM
Subject: Re: [v4tov6transition] draft-arkko-ipv6-transition-guidelines WGLC

> Well, yes, but let me carefully comment here. A problem statement is a 
> question; an FAQ is a set of answers. If the problem statement is "we have 
> some basic questions and need some answers", OK, the FAQ is both question 
> and answer. If the problem statement is something else - which I would 
> expect the IESG to want it to be if they are going to allocate time for a 
> BOF in Beijing - then an FAQ would be part of the response but not the 
> entire response, and I would expect it to be separate from and responsive 
> to the problem statement.
>
> Since I haven't seen a draft of the problem statement, it's hard for me to 
> assess that, and hard for me to contribute to the effort...
>
>>>>> disagreeing with a statement or finding additional issues that need to 
>>>>> be addressed, please post your comments to the list.
>>>>>

---

From: Tina TSOU <[email-masked]>
Date: Wed, 18 Aug 2010 10:36:06 +0800

Done. I added [email-masked] into [email-masked] 
as a whole. Hope it works now.

B. R.
Tina
----- Original Message ----- 
From: "Yiu L. Lee" <[email-masked]>
To: <[email-masked]>; "Brian E Carpenter" 
<[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, August 18, 2010 9:11 AM
Subject: Re: [v4tov6transition] draft-arkko-ipv6-transition-guidelines WGLC

>>>> It can also be part of the 
>>>> draft-lee-v4tov6transition-problem-statement,
>>>> which we are working on.
>>>

---

From: Fred Baker <[email-masked]>
Date: Tue, 17 Aug 2010 19:55:03 -0700

Does this mean we can abandon the googlegroups list?

On Aug 17, 2010, at 7:36 PM, Tina TSOU wrote:

> Done. I added [email-masked] into [email-masked] as a whole. Hope it works now.
> 
> B. R.
> Tina
> ----- Original Message ----- From: "Yiu L. Lee" <[email-masked]>
> To: <[email-masked]>; "Brian E Carpenter" <[email-masked]>

---

From: Tina TSOU <[email-masked]>
Date: Wed, 18 Aug 2010 12:00:59 +0800

Hmm, good question. If it works, let's start only use 
[email-masked].

B. R.
Tina

----- Original Message ----- 
From: "Fred Baker" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, August 18, 2010 10:55 AM
Subject: Re: [v4tov6transition] draft-arkko-ipv6-transition-guidelines WGLC

>> Done. I added [email-masked] into 
>> [email-masked] as a whole. Hope it works now.
>>
>> B. R.
>> Tina

---

From: Maglione Roberta <[email-masked]>
Date: Wed, 18 Aug 2010 10:30:16 +0200

Hi Tina, Yiu and All,
    the question I have is why do you think we could not discuss these issues in v6ops WG?
The current charter of 6vops says:
"The IPv6 Operations Working Group (v6ops) develops guidelines for the
operation of a shared IPv4/IPv6 Internet and provides operational
guidance on how to deploy IPv6 into existing IPv4-only networks,
as well as into new network installations."

and this in my opinion is exactly what you are talking about in this thread. Could you please clarify what is different here to require a separate BOF or new WG?
Thanks and best regards
Roberta

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tina TSOU
Sent: mercoledì 18 agosto 2010 3.37
To: Fred Baker; [email-masked]
Cc: [email-masked]
Subject: Re: [v4tov6transition] draft-arkko-ipv6-transition-guidelines WGLC

Fred,

Just my 2 cents.

B. R.
Tina

----- Original Message -----
From: "Fred Baker" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, August 18, 2010 4:51 AM
Subject: Re: [v4tov6transition] draft-arkko-ipv6-transition-guidelines WGLC

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

---

From: Tina TSOU <[email-masked]>
Date: Wed, 18 Aug 2010 18:49:42 +0800

Ciao Roberta,
Thank you for asking the question. We had this discussion in the Bar BoF in 
Maastricht, people may wanna comment on it. That was initiated from the 
discussion with Sheng-Yong, Lian-Yuan and Yiu. I should have invited you to 
the Bar BoF, just did not catch you after the talk in mic.

Yes, v6ops WG is one of the most important WGs in IPv6 area. It is also very 
busy; usually have 2 sessions of 2 hours for each meeting.

As replied in previous emails, V6OPS is the beginning, which sends the 
requirements to 6MAN/BEHAVE/SOFTWIRE. V6Ops focus on issues of deploying 
IPv6 into existing IPv4-only networks, with more advanced stages of 
deployment and transition a lower priority.

V4TOV6TRANSITION is the end, summarizes and applies the transition 
technologies to the existing network. As Sheng-Yong said, in the networks 
his company owns, they have solutions for v4 to v6 transition, thought they 
need a set of official documents from IETF, to tell the concrete steps for 
existing network starting v6, how these transition technologies play 
together well, not conflicting to each other, especially for the Day 1 of v4 
existing network towards v6. It might
- Solicit issues/concerns from carriers with v4v6 both deployed
- Provide suggestions on technology for solutions
- Define "handbooks (textbook)" for the operations

If possible, a short cycle, fast return, high effectiveness dedicated 
"cocktail" forum is needed, apart from heavily loaded WG v6ops. There is no 
code change request, if there is, it should go to the other WGs. It will 
cooperate with V6OPS/6MAN/BEHAVE/SOFTWIRE.

This is the end of the beginning of v4 existing network to v6!

Now we focus on the docs (problem statement, use case, transition concrete 
steps etc.) for Sep 22nd telepresence meeting.
We will have pretty idea after Sep meeting to see if a new WG is created as 
a "cocktail" WG in v4 to v6 transition aspect.

BTW, here are some questions through the email discussion these days.
1. From: Seiichi Kawamura <kawamucho at mesh.ad.jp>
How do you assign an address in your network?
   (recommended prefix length and value of interface ID)
  How do you use link-local?
  Is there RFC1918 space in IPv6?
  Is there such a thing as secondary address with IPv6?
  What's the BGP filtering boundary in IPv6 compimenting the /24 in IPv4?
  Is there a filtering guideline for IPv6?

  Why does OSPFv3 not display global scope address associated with the 
interface?
  Why is VRRPv3's global VIP optional and not implemented by some?
  What FIB size should we expect with IPv6?
  Are broacasts with IPv4 and ND with IPv6 treated the same way in my L2 
switch?
  How should be use rDNS with IPv6?

2. From: "Victor Kuarsingh" <[email-masked]>

- The drafts explain many of the technology "whats" but fall short of
describing the "hows"
- Presentation of major (generic) use case network models which exist today,
including network topologies and/or architectures
- Analysis criteria on how to recognize appropriate transition technologies
for the current provider network (such information should/would include
information related to deployed protocols and functions which may assist
and/or hinder various technologies from being deployed)
- How multiple transition technologies can be deployed (simultaneously) for
provider environments where access networks differ and have various
capabilities
- Description of how multiple technologies can co-exist during initial as
subsequent stages of migration (i.e. Moving from IPv4 Only to Dual-Stack to
DS-Lite to NAT64).
- Considerations for legacy operation while moving to IPv6 and related
transition technologies (i.e. many operators will have large caches of IPv4
only equipment which cannot be feasibly upgraded in the near future - like
customer controlled/owned)
- Considerations which need to be made when applying various technologies to
existing networks.  Included in this would be impacts to protocols, routing
platforms/systems, security polices, provisioning systems, network services
(i.e. DHCP, DNS etc), law enforcement procedures and more
- Scaling characteristics of deployment modes for each technology model and
intersections during co-existence (i.e. Some of the Network is DS-Lite and
some is Dual Stack).
- BCPs on generic deployment models (how this fits into a network) including
major and key services (i.e. DHCP, DNS)

3. From: "Yiu L. Lee" <[email-masked]>

if I was running a DSL network, what steps takes me from pure v4 to native 
dual-stack?

How to fill the gap of the v4 exhaustion?
If I chose NAT-444, what routing considerations I must consider and what are 
the pros and cons?

I know I'm talking to you people now. I'm just a person. So my thought may 
not be complete. You are welcome to put things in perspective

B. R.
Tina

----- Original Message ----- 
From: "Maglione Roberta" <[email-masked]>
To: "'Tina TSOU'" <[email-masked]>; "Fred Baker" <[email-masked]>; 
<[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; 
<[email-masked]>
Sent: Wednesday, August 18, 2010 4:30 PM
Subject: RE: [v4tov6transition] draft-arkko-ipv6-transition-guidelines WGLC

Hi Tina, Yiu and All,
    the question I have is why do you think we could not discuss these 
issues in v6ops WG?

and this in my opinion is exactly what you are talking about in this thread. 
Could you please clarify what is different here to require a separate BOF or 
new WG?
Thanks and best regards
Roberta

-----Original Message-----
From: [email-masked] 
[mailto:[email-masked]] On Behalf Of Tina TSOU
Sent: mercoledì 18 agosto 2010 3.37
To: Fred Baker; [email-masked]
Cc: [email-masked]
Subject: Re: [v4tov6transition] draft-arkko-ipv6-transition-guidelines WGLC

Fred,

Just my 2 cents.

B. R.
Tina

----- Original Message -----
From: "Fred Baker" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, August 18, 2010 4:51 AM
Subject: Re: [v4tov6transition] draft-arkko-ipv6-transition-guidelines WGLC

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle 
persone indicate. La diffusione, copia o qualsiasi altra azione derivante 
dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora 
abbiate ricevuto questo documento per errore siete cortesemente pregati di 
darne immediata comunicazione al mittente e di provvedere alla sua 
distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged 
information intended for the addressee(s) only. Dissemination, copying, 
printing or use by anybody else is unauthorised. If you are not the intended 
recipient, please delete this message and any attachments and advise the 
sender by return e-mail, Thanks.

---

From: Scott Brim <[email-masked]>
Date: Wed, 18 Aug 2010 08:07:59 -0400

On 08/17/2010 21:37 EDT, Tina TSOU wrote:
> Fred,
> You understood the procedures and how to make things easier much more
> than us. Brian does also. We see two IETF ex-chairs in this group. I'm
> so honoured working with you. I agree with you.
> 
> - multiple docs: Individual operator's use cases (Yiu, Can-Can,
> Lian-Yuan, Chris, Victor, Julien are working on them)
> - multiple docs: v4 to v6 transition steps/handbooks(should find a
> better wording, the answers of the FAQ is one of the inputs)

OK this is finally making sense to me :-)

---

From: Maglione Roberta <[email-masked]>
Date: Wed, 18 Aug 2010 16:25:25 +0200

Hi Tina,
Thanks for your answer. I agree with you in principle, as a Service Provider we need some guidelines that help us with v4 to v6 co-existence an transition phases, and we really need them now, but we should try to avoid fragmenting and/or duplicating the work in different places/working groups.
In my opinion the draft draft-arkko-ipv6-transition-guidelines already gives a good overview of how the different transition mechanisms, deployed in softwire/behave, could be applied to different deployment scenarios. We should use this as a starting point and to build in top what we thinks is still missing.  I agree with you that some topics like scalability and how different technology models can co-exist and interoperate are important pieces to be covered, but I am not fully sure that all the questions you listed below require a new IETF document to be answered. I haven't seen the problem statement, thus I may be wrong. In addition, as you probably already know, there are SDO's like Broadband Forum that are developing detailed documents that explain IPv6 typical deployment scenarios and use cases, they suggest IPv6 prefix length to be used for example for DHCPv6-PD and they also specify nodal requirements to support IPv6 in Broadband networks. I would encourage you to take a look at BBF IPv6 architectural documents like TR-187, WT-177 and WT-242.
I'll be interested in this activity, as long as, the work is kept focused on key issues, hence we do not tried to cover all the possible combination of scenarios in an academically way.
Unfortunately I won't be able to join the tele-presence meeting on September 22nd as that week there is BBF meeting, but I'll be happy to contribute and review the documents.

Best regards,
Roberta

-----Original Message-----
From: Tina TSOU [mailto:[email-masked]]
Sent: mercoledì 18 agosto 2010 12.50
To: [email-masked]; Fred Baker; Maglione Roberta
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [v4tov6transition] draft-arkko-ipv6-transition-guidelines WGLC

Ciao Roberta,

B. R.
Tina

----- Original Message -----
From: "Maglione Roberta" <[email-masked]>
To: "'Tina TSOU'" <[email-masked]>; "Fred Baker" <[email-masked]>;

Hi Tina, Yiu and All,

-----Original Message-----

Fred,

Just my 2 cents.

B. R.
Tina

---

From: Fred Baker <[email-masked]>
Date: Wed, 18 Aug 2010 10:20:34 -0700

On Aug 18, 2010, at 3:49 AM, Tina TSOU wrote:

> Yes, v6ops WG is one of the most important WGs in IPv6 area. It is also very busy; usually have 2 sessions of 2 hours for each meeting.
> 
> As replied in previous emails, V6OPS is the beginning, which sends the requirements to 6MAN/BEHAVE/SOFTWIRE. V6Ops focus on issues of deploying IPv6 into existing IPv4-only networks, with more advanced stages of deployment and transition a lower priority.

Donning my crown as Chair IPv6 Operations, and explicitly copying my co-chair and AD...

<crown>
That's actually incorrect; v6ops is about the operation of IPv6 networks. Most IPv6 networks are right now dealing with exactly the issues of deployment in existing IPv4 networks, and so yes operational deployment procedures and clarification of issues is squarely within v6ops' charter. If the reason you wanted to have this as a separate meeting was because you thought you couldn't wedge it into v6ops, you also didn't ask...

If there is a need for a new technology, yes, v6ops sends the work, in the form of requirements, to an appropriate working group. If the question is how to operationally use existing technologies, the discussion will generally stay in v6ops. I have not yet seen the proposed problem statement or other drafts, but from the discussion I would expect this to stay in v6ops.

Personally, I don't see a need for this to be a separate BOF. I'll support the activity wherever it occurs, but if the issue is that the operators would like to have a meeting separate from ongoing v6ops work to discuss the specific issues of deployment and transition, I am capable of and willing to ask for a third slot in Beijing specifically for the purpose. I would need some extra documentation; per the session request tool, "Additional slot may be available after agenda scheduling has closed and with the approval of an Area Director", which means that I need a convincing agenda to show Ron for this to happen. Even with that, in the past IETF there were a lot of working groups that didn't get *second* slots due to schedule density. But yes, it can happen, and I'm willing to make it happen or fit this discussion into the slots v6ops gets if we can't get a third slot.

I'm also willing to take the meeting on September 22nd as a webex-supported interim meeting (as opposed to Telepresence - too many locations) interim meeting of v6ops and let you run it. Due to the rules regarding interim meetings, I have some scurrying to do in the next couple of days - I need to post an announcement 30 days in advance. Doing so makes a very clear IETF footing for the meeting, however.

Up to you. http://www.ietf.org/iesg/bof-procedures.html, and the drop-dead date for a BOF request is 2010-09-13.

Oh, btw - status of documents in v6ops at this instant:

Open, not expected to continue:
	draft-azinger-cidrv6-00.txt (probably a replacement draft)
	draft-sarikaya-v6ops-prefix-delegation-01.txt
	draft-nakibly-v6ops-tunnel-loops-02.txt

Open:	draft-troan-multihoming-without-nat66-00.txt
	draft-wbeebee-v6ops-ipv6-cpe-router-bis-03.txt
	draft-korhonen-v6ops-3gpp-eps-03.txt
	draft-jiang-v6ops-nc-protection-01.txt
	draft-ietf-v6ops-v6-in-mobile-networks-01.txt

New:	draft-vandevelde-v6ops-pref-ps-00.txt

WGLC within August-October:
	draft-arkko-ipv6-transition-guidelines-04.txt
	draft-ietf-v6ops-tunnel-security-concerns-02.txt
	draft-ietf-v6ops-incremental-cgn-01.txt
	draft-narten-ipv6-3177bis-48boundary-05.txt (WG awaiting update)

IESG Evaluation:
	draft-thaler-v6ops-teredo-extensions-07.txt
	draft-ietf-v6ops-ra-guard-06.txt (IESG awaiting update)
	draft-ietf-v6ops-rogue-ra-01.txt (IESG awaiting update)
	draft-ietf-v6ops-cpe-simple-security-12.txt
	draft-gundavelli-v6ops-l2-unicast-03.txt

RFC Editor Queue:
	draft-krishnan-v6ops-teredo-update-10.txt
	draft-ietf-v6ops-v6inixp-09.txt
	draft-ietf-v6ops-isp-scenarios-00.txt
	draft-ietf-v6ops-ipv6-cpe-router-07.txt 
		(http://www.rfc-editor.org/queue2.html#draft-ietf-v6ops-ipv6-cpe-router)
	draft-baker-v6ops-greynet-05.txt

The point to take away from this is that while v6ops has had a lot (~24) documents in process over the past few months, many of them are in fact moving on. As of Beijing, I expect to have six or seven (6-7) documents on the table, which is generally what we discuss in a single 2 or 2.5 hour slot. I have already requested two slots, one for 2 hours and one for 2.5.

You may wonder why I spread WGLCs out over time. Basically, it's workload management. I find it easier to get assorted folks to look at documents if I ask them to do so within a finite amount of time (two weeks) one document at a time.

</crown>

---

From: Fred Baker <[email-masked]>
Date: Wed, 18 Aug 2010 14:36:20 -0700

Kawamura-san, I'm going to take a crack at your questions. My reason is, first, to put the answers in one place, but more importantly to point out that there are answers on the table that are available. I do find myself thinking "wiki". I suspect that there are a number of wikis around that encapsulate this information; if not, we can create one at the IETF site.

I have no doubt that I will be corrected on numerous points :-)

On Aug 16, 2010, at 9:49 PM, Seiichi Kawamura wrote:
>> On this list, would it be appropriate to ask operators to tell us what questions remain on the table?
> 
> Operators who have not yet deployed IPv6, don't know what to do at all.

OK. There's a part of me that suggests that the avenues they have followed for IPv4 will likely serve them well for IPv6 - if they got their IPv4 prefix from APNIC or CNNIC, that might be an obvious place to get an IPv6 prefix, for example. But yes, we can give them some guidelines and some educational references.

> Some want guidelines like, go and get a /32, register it in an IRR (if they do so with IPv4), check if your router supports IPv6, and if not choose a transition deployment model, route the prefix, buy transit, and finally bring some server up so the world can see you that you have IPv6. This is ISP 101 stuff that any operator should know, but some request this kind of guidance. I don't really see value in having a document that describes all these steps.

Yes:

Go to your favorite RIR and get an ISP prefix (default /32, but they want to actually ask for a prefix that will address your current footprint. In short, they will want a prefix for each of their customers, and have guidelines in their RIR's rules (/48 per customer, perhaps /52, /56, or /60 options, please don't assign /64s to networks - they are for LANs). If you need (oversimplifying dramatically, follow the logic not the specific example) a /56 for each of more than 13 million SMB customers (80% of 2^56 / 2^32), don't ask for a /32, ask for a /31 or /30 or whatever you really need. Get enough addresses that you can address all of your present customer base with one prefix. Go back for more at some later time. RFC 3177 suggests that a company's initial allocation should be large enough to handle their business for the readily-foreseeable future.

Do with that prefix pretty much what you did with IPv4...

> However, many operators who have just started and have at least some knowledge of what IPv6 is, want to know traps in advance. This I think is quite important. The differences between IPv4 and IPv6 that everyone stubles through. I've been asked these same questions over and over again.

Question. The European Commission has put together a program called 6DEPLOY; it is 2 a 3 days in-depth on the protocols. Would it make sense for deploying companies to take advantage of it?

The modules can be found in http://www.6deploy.eu/index.php?page=tutorials
An introduction into IPv6: http://www.6deploy.eu/index.php?page=e-learning

> How do you assign an address in your network? (recommended prefix length and value of interface ID)

I think a good place to start with that is 

http://www.ietf.org/rfc/rfc4291.txt
4291 IP Version 6 Addressing Architecture. R. Hinden, S. Deering.
     February 2006. (Format: TXT=52897 bytes) (Obsoletes RFC3513) (Status:
     DRAFT STANDARD)

and

http://www.ietf.org/rfc/rfc3177.txt
3177 IAB/IESG Recommendations on IPv6 Address Allocations to Sites.
     IAB, IESG. September 2001. (Format: TXT=23178 bytes) (Status:
     INFORMATIONAL)

The latter is in the process of being updated:
http://tools.ietf.org/html/draft-narten-ipv6-3177bis-48boundary
  "IPv6 Address Assignment to End Sites", Thomas Narten, Geoff Huston,
  Rosalea Roberts, 12-Jul-10

Each of the RIRs also has a policy on prefix allocation; they are similar but not necessarily exactly the same. RIPE's is at http://www.ripe.net/docs/ipv6policy.html; can someone (Randy?) supply appropriate links for all of the RIR policies?

The architecture presumes that a /64 is assigned to a LAN subnet, such as an Ethernet or WiFi domain. A recent output from 6man is found at

http://www.ietf.org/rfc/rfc5942.txt
5942 IPv6 Subnet Model: The Relationship between Links and Subnet
     Prefixes. H. Singh, W. Beebee, E. Nordmark. July 2010. (Format:
     TXT=27035 bytes) (Updates RFC4861) (Status: PROPOSED STANDARD)

and goes into that in some detail. 

The architecture presumes that the remaining 64 bits are an endpoint interface identifier. This could be the MAC Address (EUI-64 Address) in an appropriate encoding, or it could be what is called a "privacy address", which is a random number. You will find the most common approach to that, for hosts, in

http://www.ietf.org/rfc/rfc4862.txt
4862 IPv6 Stateless Address Autoconfiguration. S. Thomson, T. Narten,
     T. Jinmei. September 2007. (Format: TXT=72482 bytes) (Obsoletes
     RFC2462) (Status: DRAFT STANDARD)

http://www.ietf.org/rfc/rfc4941.txt
4941 Privacy Extensions for Stateless Address Autoconfiguration in
     IPv6. T. Narten, R. Draves, S. Krishnan. September 2007. (Format:
     TXT=56699 bytes) (Obsoletes RFC3041) (Status: DRAFT STANDARD)

There is also a DHCP option:

http://www.ietf.org/rfc/rfc3315.txt
3315 Dynamic Host Configuration Protocol for IPv6 (DHCPv6). R. Droms,
     Ed., J. Bound, B. Volz, T. Lemon, C. Perkins, M. Carney. July 2003.
     (Format: TXT=231402 bytes) (Updated by RFC4361, RFC5494) (Status:
     PROPOSED STANDARD)

That said, there are other options. One might, for example, look at

http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6inixp
http://tools.ietf.org/html/draft-ietf-v6ops-v6inixp
  "IPv6 Deployment in Internet Exchange Points (IXPs)", Roque Gagliano,
  15-Jul-10

which suggests that in an Internet Exchange Point one might use an address that helps in debugging routing exchanges. One could also look at what other folks do: guess, for example, who is using the address 2620:0:1cfe:face:b00c::3.

> How do you use link-local?

In general, link-local addresses are only used in well-defined contexts such as MLDv2, routing, and so on. Not that link-local addresses are a bad thing; they are only useful within a local subnet and therefore there isn't a lot of point in allocating DNS names for them, for example. I personally would use them in those places and otherwise forget them.

> Is there RFC1918 space in IPv6?

The counterpart is a Unique Local Address. There is a useful web site that will follow the prescribed algorithm and give you one that is or at least has a high probability of being truly unique.

http://www.ietf.org/rfc/rfc4193.txt
4193 Unique Local IPv6 Unicast Addresses. R. Hinden, B. Haberman.
    October 2005. (Format: TXT=35908 bytes) (Status: PROPOSED STANDARD)

    http://www.sixxs.net/main/

Something to understand is that at least at this point, NAT as used in IPv4 is not defined and not used in the IPv6 network, and that is generally considered a good thing. If you want a detailed discussion of the reasons, I'll refer you to some of my colleagues. :-)

> Is there such a thing as secondary address with IPv6?

To be honest, there is not a formal definition of a secondary address in IPv4. However, in IPv6, it is normal for an interface to have several addresses - for example, a network that internally uses a ULA and externally has an ISP will have three addresses on every interface - a link-local address, a ULA-based address, and a global address. If you want to consider one of those to be "secondary", be my guest.

> What's the BGP filtering boundary in IPv6 compimenting the /24 in IPv4? Is there a filtering guideline for IPv6?

That is generally an RIR recommendation. Randy or Philip, can I turn to you again for appropriate links?

In general, I think there are two considerations. One is that RIRs allocate prefixes of various lengths, mostly /32 and /48, for specific purposes. You don't want to filter out an RIR assignment - if they are allocating /48 PI space in a given prefix, within that prefix you filter to /48 at the shortest. The other is that deaggregation is generally frowned upon and at the same time generally done. I believe (I may well be wrong though) that ARIN suggests that a /32 prefix be filtered at /36, to allow "reasonable" deaggregation without going crazy. The links Randy suggests will be far better commentary on that, though.

> Operators with more experience have more specific thoughts.

That's why I'm asking Randy or Philip for help here.

> Why does OSPFv3 not display global scope address associated with the interface?

A "why did you make this decision" question might be a better question for the relevant working group. That said, from http://www.ietf.org/rfc/rfc5340.txt
5340 OSPF for IPv6. R. Coltun, D. Ferguson, J. Moy, A. Lindem. July
     2008. (Format: TXT=225664 bytes) (Obsoletes RFC2740) (Status:
     PROPOSED STANDARD)

2.3.  Addition of Flooding Scope

   Flooding scope for LSAs has been generalized and is now explicitly
   coded in the LSA's LS type field.  There are now three separate
   flooding scopes for LSAs:

   o  Link-local scope.  LSA is only flooded on the local link and no
      further.  Used for the new link-LSA.  See Section 4.4.3.8 for
      details.

   o  Area scope.  LSA is only flooded throughout a single OSPF area.
      Used for router-LSAs, network-LSAs, inter-area-prefix-LSAs, inter-
      area-router-LSAs, and intra-area-prefix-LSAs.

   o  AS scope.  LSA is flooded throughout the routing domain.  Used for
      AS-external-LSAs.  A router that originates AS scoped LSAs is
      considered an AS Boundary Router (ASBR) and will set its E-bit in
      router-LSAs for regular areas.

   On virtual links, a global scope IPv6 address MUST be used as the
   source address for OSPF protocol packets.

I think the discussion of scope in OSPF is about the scope of an LSA flood, not the scope of the address. Global scope addresses are in fact mandated in some cases and are certainly supported in all.

If I didn't understand your question, please feel free to ask more particularly.

> Why is VRRPv3's global VIP optional and not implemented by some?

Great questions for the VRRP WG and the vendors in question.

> What FIB size should we expect with IPv6?

That depends. If we enumerate edge networks - if we allocate a PI prefix to every network at the edge - we should expect the size of the FIB to be comparable to the number of edge networks in the world. That looks a lot like 10^7 in not-very-long. That was the point of Marla Azinger's discussion in IETF-78 regarding

http://tools.ietf.org/html/draft-azinger-cidrv6
  "CIDR for IPv6: Address Aggregation, Allocation, and Assignment
  Strategy", Marla Azinger, Tony Li, Jason Weil, 29-Jun-10

If we enumerate transit networks and have edge networks derive their prefixes from their upstream, using PA addressing, we should expect the size of the FIB to be some small multiple of the number of transit providers in the world (per the CIDR Report, on the order of 5000) plus the size of one's internal network. That varies a lot, of course, but there are ways to aggregate that can materially help.

In essence, that is the point of the locator/id split discussion in RRG, the discussion in

http://tools.ietf.org/html/draft-troan-multihoming-without-nat66
  "IPv6 Multihoming without Network Address Translation", Ole Troan, David
  Miles, Satoru Matsushima, Tadahisa Okimoto, Dan Wing, 26-Jul-10

and the discussions in http://tools.ietf.org/id/draft-mrw-behave-nat66 and

http://tools.ietf.org/html/draft-rja-ilnp-dns
  "DNS Resource Records for ILNP", Randall Atkinson, 24-Jun-10

http://tools.ietf.org/html/draft-rja-ilnp-icmp
  "ICMP Locator Update message", Randall Atkinson, 24-Jun-10

http://tools.ietf.org/html/draft-rja-ilnp-intro
  "ILNP Concept of Operations", Randall Atkinson, 24-Jun-10

http://tools.ietf.org/html/draft-rja-ilnp-nonce
  "Nonce Destination Option", Randall Atkinson, 24-Jun-10

I'm going to stop talking before I start a flame war...

> Are broacasts with IPv4 and ND with IPv6 treated the same way in my L2 switch?

Link layer multicast is ignorant of the network layer, apart from behaviors like MLD snooping. IPv4 Multicast and IPv6 Multicast work about the same way, modulo differences related to the address itself. That said, take a look at
http://www.ietf.org/rfc/rfc3306.txt
3306 Unicast-Prefix-based IPv6 Multicast Addresses. B. Haberman, D.
     Thaler. August 2002. (Format: TXT=12713 bytes) (Updated by RFC3956,
     RFC4489) (Status: PROPOSED STANDARD)

http://www.ietf.org/rfc/rfc3956.txt
3956 Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast
     Address. P. Savola, B. Haberman. November 2004. (Format: TXT=40136
     bytes) (Updates RFC3306) (Status: PROPOSED STANDARD)

> How should be use rDNS with IPv6?

http://en.wikipedia.org/wiki/Reverse_DNS_lookup. It is essentially as in IPv4, but uses ip6.arpa and enumerates hex rather than decimal digits.

> To summarize my long and rough comments (sorry) "what is the difference between IPv6 and IPv4 that we should be aware of?" is the question that many tend to ask and is always a popular topic in my local NOG (JANOG).

JANOG of course has extensive experience here. I suspect that it also ha a wiki in which it has captured much of this, and if JANOG has not then RIPE, IPNIC, or someone else has.

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 18 Aug 2010 14:55:01 -0700

> I'm going to stop talking before I start a flame war...

Indeed. For there to be any complete consideration of this
space, one also has to look at IRON as well as ISATAP from
whence it was derived.

Fred
[email-masked]

---

From: Fred Baker <[email-masked]>
Date: Wed, 18 Aug 2010 15:30:11 -0700

Ask and ye shall receive. Randy tells me that the wiki I was looking for is at:
	http://www.civil-tongue.net/6and4/

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 19 Aug 2010 11:32:21 +1200

Concatenated replies to several messages:

On 2010-08-19 07:45, Hemant Singh (shemant) wrote:
> None of the items in the grocery list below seem to warrant a
>  BOF or new WG.  V6ops is fully capable and chartered to 
> handle this list including not being that busy to not find 
> time for the new documents or questions.  In fact, just blast
>  new drafts to the v6ops mailing list or ask these questions 
> of v6ops mailer and folks will reply.  If a draft sent to the
>  mailer is not being discussed, let the Chairs know and they 
> will designate reviewers.  In fact some of the questions 
> asked can be answered right now.

In my opinion there is an organizational problem that
needs more than just blasting new drafts or asking questions.
Whether it is organized as a separate BOF or a special session
of V6OPS is not so important, but there are many operators who
will soon face IPv6 for the first time and they badly need
organized advice. We will only get that with an organized
discussion.

On 2010-08-19 09:36, Fred Baker wrote:

> there are answers on the table that are available. I do find
> myself thinking "wiki".

I really don't think that meets the need for well organized
advice; no disrespect to http://www.civil-tongue.net/6and4/
or its peers, but neither that nor vendors' documentation
really fills the bill IMHO.

On 2010-08-19 09:53, Cameron Byrne wrote:

> These sound more like training issues that are better handled by ops
> folks, and ops folks generally participate more in groups like NANOG
> and other *NOGs.  There are also some very relevant IPv6 operations
> mailing lists that handle tactical issues.

Correct, but again: newcomers to IPv6 need organized documents
first.

> 
> As Hermant points out above, most of these questions have straight
> forward immediate answers.  Generally, addressing a "HOW" is an
> operator specific issue that depends largely on the context and
> problem to be solve.

Absolutely. I hope nobody imagines we can produce "one size fits
all" documents.

> Also, to be frank, i do not believe the majority of the participants
> in the IETF even work or have current experience at network operators.

Then we'd better get contributions from the minority that do.

   Brian

---

From: Seiichi Kawamura <[email-masked]>
Date: Thu, 19 Aug 2010 10:04:44 +0900

Hi Fred

To make it clear, most of those question are not from me
but questions that I tend to hear from a lot of operators
around me. As Brian C. has said in a different mail,
the answers are not organized so I keep hearing the same
questions over and over again.

Rest of my comments inline.

> Do with that prefix pretty much what you did with IPv4...

Exactly. I guess it might seem hard for some people because
IPv4 networks have been around for a while and many
people have never started up a brand new Interdomain routing
network before. But there's nothing new here and just going
to RIRs will should give you enough information on what to do.

> An introduction into IPv6: http://www.6deploy.eu/index.php?page=e-learning

I haven't looked at all of these documents, but some of them are actually
pretty good. The addressing case studies is a good reference and
answers some of the questions (although the content needs to be
updated a little... many nitty stuff)

>   Rosalea Roberts, 12-Jul-10

I think the addressing case studies
from 6deploy give the best answer to this question.

> which suggests that in an Internet Exchange Point one might use an address that helps in debugging routing exchanges. One could also look at what other folks do: guess, for example, who is using th…

v6inixp is written very well and reviewed by many engineers from IXPs.
Its a document that is based on reality. Very cool.
The question that comes up these days is, what link-local address would an
connecting ISP assing on their link? We can leave it as EUI, and that's
most likely the default, but one down side to that is, sometimes you have
to look at the neighbor table, and that only shows link local addresses.
You have to go look and see which link local address is associated with
the global address you are peering with.
I set an address like fe80::2518:1 (2518 is my ASNUM).

> In general, link-local addresses are only used in well-defined contexts such as MLDv2, routing, and so on. Not that link-local addresses are a bad thing; they are only useful within a local subnet…

Sorry, the question was worded badly.
Its more of a question that asks,
should LL be in my ACL? should I assing static addresses
instead of the automatically generated ones? etc.

>     http://www.sixxs.net/main/

Actually I would answer no to that question.
The technical differences are pretty big at this point.
That includes NAT (just as you say), uniqueness, AS112, etc...
But you can say that if you wanted to use an
address to try in your lab and you don't have global
prefix allocated to you because you are not an LIR,
ULA would be one of your choices.
That would more be like TEST-NET stuff wouldn't it?

> To be honest, there is not a formal definition of a secondary address in IPv4. However, in IPv6, it is normal for an interface to have several addresses - for example, a network that internally use…

Agree :-)

> That is generally an RIR recommendation. Randy or Philip, can I turn to you again for appropriate links?

I've been asking many people "what do you filter at?"
recently. One would think that people filter at /48,
but there are many that filter at /64, some that
filter at exact allocation boudaries, and few that
filter at /32. I don't think we have common religion yet.
The differences in a "full routing table" are pretty
big right now raging from somewher around 1800-3500.

> If I didn't understand your question, please feel free to ask more particularly.

ID               Interface              State     Pri   Dead
192.168.2.1     xe-0/0/0.0             Full        1     32
  Neighbor-address fe80::2:1

Where's my global address?

> Great questions for the VRRP WG and the vendors in question.

Yes. I have asked in in the VRRP list, one
person answered that global address support is implicit.
This IMHO should be changed.

I do know about Randy's wiki, and I think it rocks.
Unfortunately, wikis only work locally. They don't
get the global attention that it deserves.
IETF does, which is why I think a discussion here is worthwhile.

Regards,
Seiichi

---

From: Ed Jankiewicz <[email-masked]>
Date: Wed, 18 Aug 2010 22:29:12 -0400

also stumbled upon this wiki maintained by ARIN

http://www.getipv6.info/index.php/First_Steps_for_ISPs

-- 
Ed Jankiewicz - SRI International
Fort Monmouth Branch Office - IPv6 Research
Supporting DISA Standards Engineering Branch
732-389-1003 or  [email-masked]

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 18 Aug 2010 21:15:46 -0700

>
> i agree that DS is not what you want off the backbone.  v6 with nat64
> should be encouraged at home and at work.  but i think you want the isps
> to have dual stack backbones for a while.

Yes, I agree.  I  tend to only speak for my use case in mobile
wireless.  The numbering problem is at the end nodes and access
providers have to feel the pain (or no gain).  DS backbone should be
old hat for the major backbone ISPs.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 18 Aug 2010 14:45:31 -0500

None of the items in the grocery list below seem to warrant a BOF or new WG.  V6ops is fully capable and chartered to handle this list including not being that busy to not find time for the new documents or questions.  In fact, just blast new drafts to the v6ops mailing list or ask these questions of v6ops mailer and folks will reply.  If a draft sent to the mailer is not being discussed, let the Chairs know and they will designate reviewers.  In fact some of the questions asked can be answered right now.

For hosts in your network see if SLAAC can be used in your network and SLAAC defaults to a /64. If not SLAAC, use DHCPv6 and see what sense it makes in your network to use for prefix length.  If your network is a SP network with edge and core routers then addressing such routers is also a well-know operation besides the controversial /127. You have to be more specific than the question above. 

   For ND operations and any other IPv6 control that travels over the link-local like MLDv2, and DHCPv6. 

   The ULA.

   No.

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tina TSOU
Sent: Wednesday, August 18, 2010 6:50 AM
To: [email-masked]; Fred Baker (fred); Maglione Roberta
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [v4tov6transition] draft-arkko-ipv6-transition-guidelines WGLC

Ciao Roberta,

B. R.
Tina

----- Original Message ----- 
From: "Maglione Roberta" <[email-masked]>
To: "'Tina TSOU'" <[email-masked]>; "Fred Baker" <[email-masked]>; 

Hi Tina, Yiu and All,

-----Original Message-----

Fred,

Just my 2 cents.

B. R.
Tina

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 18 Aug 2010 14:53:47 -0700

As Hermant points out above, most of these questions have straight
forward immediate answers.  Generally, addressing a "HOW" is an
operator specific issue that depends largely on the context and
problem to be solve.  Budget, existing systems, timeline ... they
determine the "HOW", not the IETF.  Nobody told me "HOW" to build my
IPv4 networks, and if somebody tried, i am unsure the "HOW" would be
universally.

Also, to be frank, i do not believe the majority of the participants
in the IETF even work or have current experience at network operators.
 The IETF folks are great and very helpful and Jari's draft is a good
example of how the IETF can be helpful.  Jari has helped paint the
picture and catalog the options, and he has not gone further than that
because there would not be value in going further.

Cameron

---

From: Randy Bush <[email-masked]>
Date: Thu, 19 Aug 2010 11:51:33 +0900

> Thanks for your answer. I agree with you in principle, as a Service
> Provider we need some guidelines that help us with v4 to v6
> co-existence an transition phases, and we really need them now, but we
> should try to avoid fragmenting and/or duplicating the work in
> different places/working groups.

<rant>

bingo!  we already did ng6trans, i think it was called.  it exploded in
a thousand pieces of mostly unnecessary inventions.  but lots of folk
did get on author lists.

i would also caution against exploring the space of how to make it so
that networks that have been sickly broken with things such as cgn can
claim to also handle ipv6.  make your bed, lie in it.  let cgn have fun
in behave or wherever.

and the working tunnel-v6-through-v4 tools we have either work through
the we-can-sell-monsterous-spof-to-carriers or they can hack on the
perpetuata-ipv4-and-rfc1918-forever gadgets until the v6 tunneling tools
do work.  just do it under a rock where such things belong.

sez Fred Baker <[email-masked]>:

> That's actually incorrect; v6ops is about the operation of IPv6 networks

yep.  but not about how to pretend an rfc 1918 v4 network can be called
a v6 network.

<portmanteau>

sez From: Cameron Byrne <[email-masked]>

> ...

both ears and the tail!

> Then we'd better get contributions from the minority that do.

where was that box of q-tips?

sez Cameron Byrne <[email-masked]>:

> IMHO, traditional dual-stack is not viable for transition.  There are
> not incentives for me to dual stack at home, work, or while mobile.

randy

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 19 Aug 2010 09:04:54 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Randy Bush
> Sent: Wednesday, August 18, 2010 7:52 PM
> To: [email-masked]; [email-masked]

This seems like it could be misinterpreted through exaggeration;
for example, I certainly don't see thousands of pieces. It also
seems to take a swipe at contributors who have helped shape the
standards through consistent hard work over the course of many
years.

Fred

---

From: Jari Arkko <[email-masked]>
Date: Fri, 20 Aug 2010 09:06:27 -0400

Brian, Fred, et al,

I also think that there is plenty of work left to do in terms of 
providing guidance to network operators on how they should deploy IPv6. 
(I'm not saying that we should add all of it to draft-arkko, though :-)

I very much agree with Brian that we need to have well organized answers 
for all the operational guidance issues. And we do not necessarily have 
all well organized yet. One of the questions coming from this thread 
appears to be where to go for advice when you are starting from ground 
up. But I do think that we have to take time to figure out exactly what 
advice we can already point to, what new work may be needed on top of 
that, and where that new work will happen and by whom.

Its not even always clear that the IETF is the best place for all work 
in this space; the operational forums, various training institutions, 
etc. will also play a role. But one idea might be to reserve some time 
in the next V6OPS session (perhaps a third slot) for a discussion of 
this topic: what operational guidance do we have and what is missing? 
Sort of a high-level review of the situation as opposed to the 
relatively small details that we often spend most of our time on.

Jari

---

From: Fred Baker <[email-masked]>
Date: Fri, 20 Aug 2010 10:55:07 -0700

I'd appreciate remarks on the proposed update at

    ftp://ftpeng.cisco.com/fred/v6ops/transition-diffs.html
    ftp://ftpeng.cisco.com/fred/v6ops/transition-guideline.txt
    ftp://ftpeng.cisco.com/fred/v6ops/transition-guideline.xml

If you believe that I have addressed your concerns regarding 4.4 and timing, I'll post that as an update-in-WGLC.

I'll comment on your comments inline.

On Aug 20, 2010, at 9:08 AM, Cameron Byrne wrote:

> On Fri, Aug 20, 2010 at 6:56 AM, Cameron Byrne <[email-masked]> wrote:
>> On Sun, Aug 15, 2010 at 11:00 AM, Fred Baker <[email-masked]> wrote:
>>> This is to initiate a two week working group last call
>>> of draft-arkko-ipv6-transition-guidelines. Please read it now. If you find
>>> nits (spelling errors, minor suggested wording changes, etc), comment to the
>>> authors; if you find greater issues, such as disagreeing with a statement or
>>> finding additional issues that need to be addressed, please post your
>>> comments to the list.
>>> We are looking specifically for comments on the importance of the document
>>> as well as its content. If you have read the document and believe it to be
>>> of operational utility, that is also an important comment to make.
>> 
>> My feed back is this document, as it stands,  is not an operational
>> utility since I do not believe it helps people in operating an access
>> network (most networks have end nodes on them, backbone ISPs know what
>> to do).  Do we need yet another anthology of IPv6 tools?  I do not
>> think there is good reason that this document should move forward
>> since it does not add anything new or, IMHO, good advice to people
>> with numbering problems.
>> 

You have seen, in the past few days, comments cross-posted to [email-masked]; I believe that you are also on that list. This is a set of service providers that are specifically asking the IETF for guidance on how to go about IPv6 deployment and eventual transition. Jari originated this document because he is asked the question, and many of us are.

>> Here are my concerns:
>> 
>> 1.  The only reason people want to deploy IPv6 is because of IPv4
>> exhaust, right?   Yet this document  recommends dual-stack as the
>> right approach forward.

May I invite you to look at RFC 4192? You will recall that it was intended to be the first draft of an operational renumbering plan; if someone wants to renumber their network or a part of it, they can look at this for a general structure. I would expect them to draft what I will call a "second draft", that follows the guidelines, addresses the issues raised, and is tailored to their network and its needs.

"Dual Stack" is a renumbering plan, if you will. Instead of renumbering an IPv6 network, it renumbers an IPv4 network as an an IPv6 network. RFC 4192 explicitly addresses business continuity on the existing numbering plane (IPv4 in this case) during deployment, and discusses how one tells whether and when one is ready to shift to the new numbering plan (IPv6 in this case), and ultimately how to turn down the old numbering plan.

I find your remark here confusing. Why would one disrupt one's own business for a network reason? Why would one not seek to continue their business operations during the change? Help me out here.

>> The IETF should know that DS does not solve a
>> numbering problem and there is no incentive for folks to go dual
>> stack. DS is pure altruism to make IPv6 easier to the stragglers and
>> free-riders.  But, even technology forward companies like Cisco and
>> Ericsson do not have dual stack websites today, 10+ years after the
>> IETF told everyone they should go DS.  So once again, from on high,
>> "do as I say, not as i do".
>> 

Actually, we do have some help for IPv4 numbering issues; the translation technology that we have developed in behave and comment on in 4.4 enables a network to carefully husband its IPv4 address space by allocating it (stateless translation) as IPv4-accessible IPv4-embedded IPv6 addresses applied to servers, and deploy ipv6-only clients - historically 40:1 over servers - that can access IPv4 servers using a translation technology not so very different from the IPv4/IPv4 NAT in current wide use. During the IPv6 deployment, there remains a very real question of business continuity; there will be no flag day, which means that there will for a period of time be systems that either have not got IPv4 enabled or whose networks are not IPv6-clean end to end, and this kind of thing can help.

>> 2.  If this document is to take a realist view and assert the IETF
>> position as a though leader and guide to the future, it should paint
>> the real picture of IPv4 exhaust and provide real solutions to what
>> happens when there is no more IPv4 to be had.  It should also, for
>> historical perspective, explain why DS did not work so people can
>> avoid going down this path.... or at the least, know that going DS is
>> not the end-state where we don't have to worry about IPv4 any more
>> .... DS is just a multi-protocol network that is more expensive and
>> more complicated.  In some corners of the world, when i tell people DS
>> does not solve the number problem, it is the first time they have
>> looked at DS with a critical eye.
>> 

Which is to say that you have convinced them that they actually have to turn on IPv6, and good for you. Understand that dual stack has not failed for anyone that has tried it. What has failed is "not turning on IPv6".

>> 3..  Fred made it clear that deployment is turning something on.
>> Transition is turning something off.  This document is called
>> transition but it does not recommend or articulate how to turn IPv4
>> off in any detail.
>> 

I believe that you are referring to the title of the document. the title is "Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment", not "how to carry out an IPv4 to IPv6 transition". I believe that RFC 5211 gives some thoughts about the latter.

>> 4.  Perhaps it would be helpful to specify a scope for this document?
>> Enterprise networks?  Access networks?  Transit ISPs?
>> 

It might be, but here I would be interested in comments from people in those various networks.

In private email, you castigated me for saying anything on IPv6 deployment at all, as in your words "Cisco is not deploying IPv6". I'll repeat for the record the comment I sent in private email.

/*****
 * comment from private email
 *****/
As you may be aware, Cisco is in the process of internal deployment; IPv6 is deployed in parts of the company, and as I type I am on a phone call related to the deployment itself. That deployment will be dual stack. The reason it is dual stack is that Cisco is not stopping doing business during the transition; we still need to communicate with customers and business partners that have not yet deployed, and world-wide we have roughly 100,000 people that have to do their work during the transition.

When IPv6 has been fully deployed throughout Cisco, a process started a year ago and which I expect will take the coming year, Cisco will start asking the question of IPv4 turn-down. That will not be a technical decision; it will be a business decision. One by one, I would expect Cisco to temporarily and then permanently disable IPv4 access to various internal applications. When Cisco has no more internal applications running that use IPv4, the only real use of IPv4 in Cisco will be access to the outside world. At some point, I would expect Cisco to determine that the business need to use IPv4 to do that has diminished, and IPv4 support is no longer needed.

Very honestly, the turn-down process is not a priority for Cisco. The equipment and configurations required for IPv4 are sunk cost, and the bandwidth is essentially the same whether IPv4 or IPv6. I expect the turn-down process to take as long as is necessary, and probably a lot longer.

Who am I to tell people to do dual stack? Someone who is doing dual stack, and whose corporate share-holders and management will consider nothing else.
/*****
 *****/

If I am incorrect, I know someone will correct me; my guess is that the fundamental needs of enterprise, access, and transit networks are roughly the same, although they are discussed and carried out in different ways. 

First, we all need enough addresses to run our businesses, whether we are edge networks, access networks, or transit networks.

Not all are feeling the address pinch yet, and a surprising number of edge networks that I talk with don't expect an address pinch at all. The issue of address availability applies to networks that need a flow of address space to deploy new services or meet new customer needs; businesses that don't require addresses to do that don't have that requirement. So when I say that IPv4 addresses are running out, those businesses yawn. For them, the issue that the coming few years impose is one of accessibility to business partners that do have the issue and as a result will deploy. Call that "denial" if you like; it's a viewpoint that I hear expressed.

Any network that does require additional address space from time to time is looking at a continuity of business situation. Not continuity of business with its existing infrastructure, which is paid-in-full, operational, and working, but its new businesses, services, or customer bases. It will deploy IPv6 to meet that new addressing need.

Second, we all need to serve the needs of our customers. Those "customers" may be employees, who need to use the network to access applications relevant to the operation of our own business, or who need to talk with business partners and corporate clients in the course of doing business. They may literally be customers in the case of access networks, or peers in the case of transit networks. 

These face a problem - many of their employees or customers require access to the IPv4 Internet in some form while that deployment is happening, and turning up IPv6 requires them to audit their networks (does the current software support what they want to do? If not, do they need new hardware to deploy the needed new software?), prove out new configurations, and turn them up. As you know, that is not a matter of snapping one's fingers. If they had started when they should have, it would literally have been a matter of turning up IPv6 in their existing IPv4 networks; they didn't, and many are now turning to some variation on CGN as described in draft-ietf-v6ops-incremental-cgn to keep IPv4 services stumbling along while they deploy. 

You would like us to tell people to, while they are turning IPv6 on, to turn IPv4 off or in their new network zones deploy no IPv4 capability. This doesn't work, due to business continuity. At some point in the future, an IPv6-only service that is not a walled garden will be feasible; today, without IPv4 service, nothing on the IPv4 Internet - by every estimate I see larger than 95% of the Internet - is accessible. I have above given you a very clear view of the implications of that for an edge network; for an access network, selling a service that fails to provide access seems an oxymoron, and for a transit network, it's a dead end. I fail to see how any network, SOHO, SMB, Enterprise, Access, or Transit, is served by failing to meet the needs of its employees or customers.

> 1. Please reconsider explicitly recommending dual stack.  Perhaps put
> it some verbiage about "no pain, no gain"

In view of my argument above, what argument should I give that will convince someone to discontinue their current business operation while they deploy IPv6?

> 2. Revise statement about literals.  The current unqualified and
> unbounded statement without context gives the wrong impression.

I believe that I have addressed your comments in
     ftp://ftpeng.cisco.com/fred/v6ops/transition-guideline.txt

I would appreciate your further constructive remarks.

> 3. Squarely face the issue of a fragmented internet where there is
> ipv6.google.com, ipv6.t-mobile.com, www.ipv6.cisco.com
> www.v6.facebook.com as well as aaaa whitelist that Yahoo and Google
> are pushing.  I believe the reality of these sites and the DNS
> whitelist are more votes against DS.

http://www.ipv6.cisco.com/, like IPv6.Google.Com and IPv6.Facebook.Com, is indeed IPv6-only. There is a reason, and it has nothing to do with deploying a perfectly usable service. It is to test access to Cisco's public web site using IPv6. What purpose would dual stack deployment have in that context?

In time, I fully expect the deployment of AAAA records for www.cisco.com and its counterparts at the other companies you mention. That will not be a "trial" scenario; it will be a "service" scenario. I think the correct way to read the existence of sites like these that are IPv6-only and force one to "do something different" to get to them is that the companies don't yet consider them to be ready for prime time.

Given that, I'm not sure what you are asking me to squarely face. I would, though, invite you to squarely face the business requirements of networks that are deploying in a dual stack configuration. 

If you would like, we could jointly look at an RFC 4192 follow-on that discusses the process of transition. I suspect, though, that the "transition" part, the part where we turn down IPv4, will in most places be as it is at Cisco - a business matter. IPv4 will stay up while there is a business need, and will probably stay up for a period of time when there is no remaining real business need "just in case". It will be turned down when its day is simply over.

---

From: Cameron Byrne <[email-masked]>
Date: Fri, 20 Aug 2010 12:10:39 -0700

> I find your remark here confusing. Why would one disrupt one's own business for a network reason? Why would one not seek to continue their business operations during the change? Help me out here.

Sorry, i have my mobile network blinders on.  In the USA, generally
speaking, large corporations and fixed line providers are not growing
subscribers at a very fast pace.  Mobile data subscribers, on the
other hand, are growing very fast and with M2M they will grow faster.
Not having IPv4 addresses available is a serious business continuity
issue we have in the near term.  Mobile providers in the USA use
N*RFC1918 or BOGONs.  VZW at the Google conference said they have
40*net-10, and AT&T has a similar issues, and these issues have
hampered innovation in the IMS/SIP, e2e, p2p space ... lots of SIP
B2BUA attempting to stitch together overlapping address space.

And, as i have pointed out before in various forums, today's 3G
networks require 2x the signalling and packet core cost for dual stack
users (2x bearers, 2x mobility events, 2x many things ...).  Yes, the
costs change in LTE .... LTE will not be mainstream before IPv4
Exhaust.

> Which is to say that you have convinced them that they actually have to turn on IPv6, and good for you. Understand that dual stack has not failed for anyone that has tried it. What has failed is "n…

My free advice does not go nearly as far as codified IETF document.  I
cannot take credit for convince anyone of anything.

Regarding dual-stack has not failed anyone, i direct you to the Yahoo
and Google discussions about DNS white listing.
http://www.ietf.org/proceedings/10mar/slides/dnsop-7.pdf

I also site that dual-stack in 3GPP before release 9 is 2x the cost.
I cannot ask "the business" guys to 2x the packet core network budget
to support 2x the PDP bearers + all that IPv4 NAT.

> Not all are feeling the address pinch yet, and a surprising number of edge networks that I talk with don't expect an address pinch at all. The issue of address availability applies to networks that…

Onces again, i site my mobile focus.  I understand people that have
IPv4 addresses and are not experiencing exponential growth at the edge
may not be concerned.

> In view of my argument above, what argument should I give that will convince someone to discontinue their current business operation while they deploy IPv6?

IPv4 is not going away. But, IPv6-only host must emerge as the edge
grows (mobile ..., M2M, ...)

---

From: Fred Baker <[email-masked]>
Date: Fri, 20 Aug 2010 13:41:12 -0700

On Aug 20, 2010, at 12:10 PM, Cameron Byrne wrote:

> IPv6-only host must emerge as the edge grows (mobile ..., M2M, ...)

I certainly agree with that. Understand that mobile handsets are already and increasingly both IPv4 and IPv6 capable. The issue is in the network, and it is in the applications that those handsets use. The applications like to call gethostbyname() instead of getaddrinfo(), and as a result are IPv4-aware instead of being network layer agnostic. That was Hui Deng's point in the two 3GPP/IETF joint workshops and in the pnat discussion in behave. This document grew out of a powerpoint presentation, pointed to as an informative reference, that I gave at the first of those workshops, and summarizes both that talk and Jari's experience using Ericsson's NAT64 solution at home.

If I were king, and note that I am not at this instant wearing my shiny working group chair crown, I'm wearing my dusty author's beret, gethostbyname would disappear and applications that use it would be given the option of complaining to /dev/null or fixing their code. At some point, maybe the 3G vendors could help us out there...

---

From: Cameron Byrne <[email-masked]>
Date: Fri, 20 Aug 2010 15:51:57 -0700

On Fri, Aug 20, 2010 at 12:50 PM, Mikael Abrahamsson <[email-masked]> wrote:
> On Fri, 20 Aug 2010, Cameron Byrne wrote:
>
>> And, as i have pointed out before in various forums, today's 3G networks
>> require 2x the signalling and packet core cost for dual stack users (2x
>> bearers, 2x mobility events, 2x many things ...).  Yes, the costs change in
>> LTE .... LTE will not be mainstream before IPv4 Exhaust.
>
> I would like to question the 2x cost.
>
> Yes, multi-bearer per user license cost money, so does handling 2x numbers
> of bearer, but the number of packets isn't going to be 2x so actual packet
> moving hw won't be even close to 2x cost. More license, more
> HLR/MME/SPGW/GGSN/SGSN signalling, but not more packets.

Agreed.  The 2x cost is really just the packet core ... which is of
course a lot of money to double for no tangible benefit ..... talk
about no business case .... And, still have numbering issues, customer
experience is the same as IPv4-only + NAT44 and approximately the same
as IPv6-only + NAT64

>
> I also don't really see how LTE changes things dramatically in this aspect,
> to enable roaming we're going to be stuck at GTPv1 bearers for the
> forseeable future (IMHO), so we're still going to have to do 2x PDP context
> for users with IPv4 and IPv6 dual stack.
>

If you do dual-stack services, yes.  The model i am driving for is
IPv6-only when in-network and IPv4-only when roaming.  I believe this
is the practical approach given that billing for IPv6 roaming will be
very slow.

> It might even be that ds.lite with ipv6 only to the phone makes more sense
> here because I'd imagine that enables roaming with single PDP context/bearer
> instead of multiple, and I'd imagine the roaming network doesn't really care
> if the user has IPv4 or IPv6? I'm not a roaming expert though, might be
> wrong.
>

IMHO, i don't see a good fit for DSlite on traditional mobile
handsets, and that i believe was the conclusion of the 3GPP-IETF
meeting in San Fran.  Perhap there is a good fit for DSlite + mobile
hotspots (MiFi).

> --
> Mikael Abrahamsson    email: [email-masked]
>

---

From: Cameron Byrne <[email-masked]>
Date: Fri, 20 Aug 2010 16:06:50 -0700

> I certainly agree with that. Understand that mobile handsets are already and increasingly both IPv4 and IPv6 capable. The issue is in the network, and it is in the applications that those handsets…

Just focusing on mobile, here ... Jari states IPv6-only works well for
mobile.  I believe one of his docs (Google preso)  states it
approaches 100% functionality.

PNAT did not achieve much support and was not advanced (right?),
despite a strong effort from Hui.

Like IPv4 literals, i believe the general issues in mobile apps are
trivial.  I presented my experience at the Google conference.  Notice
not many apps are impacted
https://sites.google.com/site/ipv6implementors/2010/agenda/13_Byrne_T-Mobile_IPv6GoogleMeeting.pdf

My FUT users, along with my own experience, is that very few apps fail
when ipv6-only

http://groups.google.com/group/tmoipv6beta/browse_thread/thread/6fc0633f0313b588

I understand that the desktop space, and in particular games and
skype, have problems with IPv6-only.  But, mobile is different.  The
SDKs for Apple, Symbian, and Android have done a good job at forcing
the developers to be IP version agnostic..... which means most apps
are IPv6 capable by default, not by app designers own volition.

> If I were king, and note that I am not at this instant wearing my shiny working group chair crown, I'm wearing my dusty author's beret, gethostbyname would disappear and applications that use it wo…

As far as i can tell, for the most part, your desire has been
achieved.  If you believe otherwise, please contact me off list to
find out how you can join the IPv6-only beta.

Cameron

---

From: "Yiu L. Lee" <[email-masked]>
Date: Fri, 20 Aug 2010 19:37:26 -0400

> experience is the same as IPv4-only + NAT44 and approximately the same
Life cycle of mobile equipments could be every 2-3 years, but life cycle of
consumer electronics could be 5+ years. Consider many large TVs with
Internet service selling today are still running IPv4-only, fixed line
operators must prepare to support them in foreseeable future.

That said, I am not saying an operator must build a dual-stack core network,
there are technologies such as DS-lite and Softwire Mesh available to run a
pure IPv6 core network with dual-stack edge. All I am saying is the customer
experience of IPv4-only + NAT444 could be the same as IPv6-only + NAT64, but
the technologies and plan to offer these service are very different.

---

From: Cameron Byrne <[email-masked]>
Date: Fri, 20 Aug 2010 16:45:59 -0700

> operators must prepare to support them in foreseeable future.

Depends what box you are talking about, but our accountants like 5+
years for gear.... GSM gear is still around and not going anywhere for
a long time.  Other network functions, especially NAT and stateful IP
stuff expires quicker.  I can say that mobile phone lifecycle is
between 9 and 24 months.... which is quick.

> the technologies and plan to offer these service are very different.

Agreed.  3GPP mobile  can do native v6 easy.  Other network types, not so easy.

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 20 Aug 2010 17:56:45 -0700

> From: [email-masked] [mailto:v4tov6transition-
> [email-masked]] On Behalf Of Cameron Byrne
> Sent: Friday, August 20, 2010 4:07 PM
> To: Fred Baker
> Cc: IPv6 v6ops; Ron Bonica; [email-masked]; Kurt Erik
> Lindqvist
> > I certainly agree with that. Understand that mobile handsets are
> already and increasingly both IPv4 and IPv6 capable. The issue is in
> the network, and it is in the applications that those handsets use. The
> applications like to call gethostbyname() instead of getaddrinfo(), and
> as a result are IPv4-aware instead of being network layer agnostic.
> That was Hui Deng's point in the two 3GPP/IETF joint workshops and in
> the pnat discussion in behave. This document grew out of a powerpoint
> presentation, pointed to as an informative reference, that I gave at
> the first of those workshops, and summarizes both that talk and Jari's
> experience using Ericsson's NAT64 solution at home.
> >
> 

The in-host IPv4->IPv6 translation aspect of PNAT is alive, 
http://tools.ietf.org/html/draft-huang-behave-bih-01, and is
part of the currently-planned charter for BEHAVE,
http://www.ietf.org/mail-archive/web/behave/current/msg08688.html,
"Apr 2011, Submit to IESG: host-based NAT46 translation for 
           IPv4-only applications to access IPv6-only servers (std)".

Send feedback to [email-masked]

-d

> > If I were king, and note that I am not at this instant wearing my
> shiny working group chair crown, I'm wearing my dusty author's beret,
> gethostbyname would disappear and applications that use it would be
> given the option of complaining to /dev/null or fixing their code. At
> some point, maybe the 3G vendors could help us out there...
>

---

From: Jari Arkko <[email-masked]>
Date: Sat, 21 Aug 2010 09:20:18 -0400

Cameron,

> Jari states IPv6-only works well for

Yes, though for the record, draft-arkko-ipv6-only-experience does say 
that under certain assumptions (the ability to pick the right user 
devices) you reach 100% functionality.

I do believe that IPv6-only (with nat64) is an excellent approach for 
mobile networks, and I hope we will soon see this in widespread 
commercial usage. Perhaps in your network :-)

That being said, I do not want to give the impression that its a piece 
of cake either. The assumption above is a tough requirement, and for 
sure there'll be plenty of other work ahead as well. I do stand by my 
recommendation that *at this time* even for mobile operators, dual stack 
should be the default strategy even if some networks are going for 
IPv6-only. I am aware of the additional complexities on the dual stack 
side as well. In any case, I believe that a few years down the road the 
recommendation will be different, i.e., enough software and user 
equipment have matured so that IPv6-only can be considered as the 
default strategy. Of course, some networks have to be at the forefront. 
They will be the leaders, but will also get the initial pains from 
hitting various issues first.

Anyway, what are we really discussing here about? The document *does* 
recommend all four different models. I think we do have deployment 
evidence that speaks in favor of dual stack being the most problem free 
(at the moment), so this is why it is discussed first and described as 
the default strategy. I would be happy to use more accurate or different 
wording, but I don't think that you are arguing either that some of the 
models should go away. Would you like us to add something more specific 
about types of networks (e.g., mobile) where translation-based model is 
recommended?

Jari

---

From: Cameron Byrne <[email-masked]>
Date: Sat, 21 Aug 2010 06:49:26 -0700

>
> Yes, though for the record, draft-arkko-ipv6-only-experience does say that
> under certain assumptions (the ability to pick the right user devices) you
> reach 100% functionality.
>

I would be very happy if we included the above point in the transition
draft section 4.4

> I do believe that IPv6-only (with nat64) is an excellent approach for mobile
> networks, and I hope we will soon see this in widespread commercial usage.

And this above point too.

The draft only includes a green field corporate LAN as the use case
for IPv6-only.... and testing.  I believe adding the above points will
add mobile IPv6-only APNs as another relevant use case, not for
special purpose sensor networks, but generic IPv6 capable phones with
NAT64 systems to access the Internet.

I am perfectly fine with saying that dual-stack is the default IETF
recommended strategy as long as we also say that with some
consideration  and qualifications IPv6-only can be just as capable.

Thanks Jari.

Cameorn

---

From: Hui Deng <[email-masked]>
Date: Sat, 21 Aug 2010 23:17:38 +0800

2010/8/21 Cameron Byrne <[email-masked]>

> that
> mobile

I would also like to support it, it should work and could be a potential way
for future operator's selection.

-Hui

---

From: Jari Arkko <[email-masked]>
Date: Sat, 21 Aug 2010 22:54:43 -0400

Cameron,

> I would be very happy if we included the above point in the transition

That's certainly fine (and Fred has already submitted a new version).
> consideration  and qualifications IPv6-only can be just as capable.

OK -- then we are on the same page!

> Thanks Jari.

Thank you.

Jari

---

From: huang cancan <[email-masked]>
Date: Mon, 23 Aug 2010 10:21:04 +0800

hi, everybody, I am Can-can Huang from China Telecom. I can not sent mail to
the group through my working mail [email-masked].  Since it is not meet
the China Telecom's principle to use private mail for work, and I guess the
ietf mail list filter the domain name @gsta.com, does the webmaster help to
deal this problem?

Thanks!

Can-can Huang

China Telecom

---

From: Fred Baker <[email-masked]>
Date: Sun, 22 Aug 2010 19:37:28 -0700

If you are having trouble with the IETF mailer, please drop a note to [email-masked], where it will be assigned a trouble ticket and dealt with.

What leads you to believe that @gasta.com is filtered? 

On Aug 22, 2010, at 7:21 PM, huang cancan wrote:

> hi, everybody, I am Can-can Huang from China Telecom. I can not sent mail to the group through my working mail [email-masked].  Since it is not meet the China Telecom's principle to use private mail for work, and I guess the ietf mail list filter the domain name @gsta.com, does the webmaster help to deal this problem?
>  
> Thanks!
>  
> Can-can Huang
>  
> China Telecom
>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 20 Aug 2010 21:50:30 +0200 (CEST)

On Fri, 20 Aug 2010, Cameron Byrne wrote:

> bearers, 2x mobility events, 2x many things ...).  Yes, the costs change 
> in LTE .... LTE will not be mainstream before IPv4 Exhaust.

I also don't really see how LTE changes things dramatically in this 
aspect, to enable roaming we're going to be stuck at GTPv1 bearers for the 
forseeable future (IMHO), so we're still going to have to do 2x PDP 
context for users with IPv4 and IPv6 dual stack.

It might even be that ds.lite with ipv6 only to the phone makes more sense 
here because I'd imagine that enables roaming with single PDP 
context/bearer instead of multiple, and I'd imagine the roaming network 
doesn't really care if the user has IPv4 or IPv6? I'm not a roaming expert 
though, might be wrong.

---

From: Fred Baker <[email-masked]>
Date: Sun, 22 Aug 2010 22:03:04 -0700

I asked AMS about the issue that Huang Cancan reports, and got this response. Tina, you wondered the other day about what it takes to get the IETF-hosted list to support the list membership. May I suggest that the list membership also investigate the configuration of its mail servers?

On Aug 22, 2010, at 9:50 PM, Glen Barney (AMS) wrote:

> On Sun, Aug 22, 2010 at 09:26:31PM -0700, Fred Baker wrote:
>> OK, so let me ask another question. <[email-masked]> seems to be
>> having troubles on [email-masked].
>> <[email-masked]> works. He asserts that @gsta.com is
>> blocked; if it is, I'll bet it has to do with various public
>> blacklisting sites. Is it? Can you help him sort out his issue
>> please?
>>> I have sent 5~6 email to v4tov6transition@ietf .org from
>> @gsta.com, my colleagues and some people from other company didn't
>> receive them. Some of my colleague meets the same problem. I also
>> tried @189.cn,@163.com, they all failed. At last, Gmail successed.
> 
> It has nothing - at this stage, anyway - to do with public blacklisting
> sites, and I can absolutely help him sort this out.
> 
> The hosts he is using to send mail from "gsta.com" and/or "163.com" are 
> not correctly configured - there is no reverse DNS set up for either of the 
> incoming hosts.  (I see no traffic from 189.cn at all - at least not by name.)
> 
> Aug 21 21:52:24 core3 postfix/smtpd[22019]: NOQUEUE: reject: RCPT from unknown[183.11.112.220]: 450 4.7.1 Client host rejected: cannot find your reverse hostname, [183.11.112.220]; from=<[email-masked]> to=<[email-masked]> proto=ESMTP helo=<163.com>
> 
> Aug 21 22:00:50 core3 postfix/smtpd[23609]: NOQUEUE: reject: RCPT from unknown[61.144.66.75]: 450 4.7.1 Client host rejected: cannot find your reverse hostname, [61.144.66.75]; from=<[email-masked]> to=<[email-masked]> proto=ESMTP helo=<gsta.com>
> 
> As a result, mail from those hosts is rejected by the IETF servers.  (I know
> the first line above, for 163.com, is not the email from him specifically;
> however, it does illustrate that their hosts are not configured properly.)
> 
> Any public facing mail host "should" have forward and reverse DNS records
> properly set up and configured.  I say "should", but if you want to send
> email to the IETF, that becomes a "MUST".  The records must exist, they
> must match each other and the host, and they must match in some loose form
> the sender's email address and envelope information.
> 
> The IETF does not accept any mail from unlisted hosts, for two reasons.
> 
> #1. There is no good reason why a public-facing host should be unlisted, and,
> #2. 99.999999999% of all mail from such hosts is spam/UBE/UCE.
> 
> If he wishes to continue to send mail from those hosts, he should contact
> his domain administrator, and have DNS records put in for those hosts.  As
> more and more mail services adopt these procedures, unlisted servers will
> become less and less successful at sending mail.
> 
> The mail from GMAIL succeeded because GMAIL, of course, is properly set up.
> 
> Hope this helps!  Let me know if you need more!
> 
> Warm regards,
> Glen

---

From: huang cancan <[email-masked]>
Date: Wed, 25 Aug 2010 19:13:20 +0800

hi,Yiu:
  As you mentioned below:
> All I am saying is the customer

  Do you have any test data to support this conclusion?

Can-can Huang

---

From: "Yiu L. Lee" <[email-masked]>
Date: Wed, 25 Aug 2010 09:24:26 -0400

In order to deploy IPv6-only + NAT64, the client and network must talk IPv6.
It also requires DNS64. These requirements are not needed for IPv4-only +
NAT444. From the deployment point of view, they are very different
technologies.

On 8/25/10 7:13 AM, "huang cancan" <[email-masked]> wrote:

>> > experience of IPv4-only + NAT444 could be the same as IPv6-only + NAT64, >>
but
> On Sat, Aug 21, 2010 at 7:37 AM, Yiu L. Lee <[email-masked]> wrote:
>>

---

From: huang cancan <[email-masked]>
Date: Wed, 25 Aug 2010 21:41:11 +0800

well, I mean: why customer experience of IPv4-only + NAT444 could be the
same as IPv6-only + NAT64?

On Wed, Aug 25, 2010 at 9:24 PM, Yiu L. Lee <[email-masked]>wrote:

> In order to deploy IPv6-only + NAT64, the client and network must talk
> IPv6. It also requires DNS64. These requirements are not needed for
> IPv4-only + NAT444. From the deployment point of view, they are very
> different technologies.
>
>
>

---

From: "Yiu L. Lee" <[email-masked]>
Date: Wed, 25 Aug 2010 10:05:24 -0400

>From user¹s perspective, do they care IPv4 or IPv6? Most don¹t. For example:
a casual web user wants to access his/her favorite IPv4-only website. If his
web client and PC support IPv6 and on an IPv6-only network with NAT64, the
web traffic will go through the NAT once. If his web client and PC support
IPv4-only on an IPv4 network with NAT444, the web traffic will go through
the NAT twice. In the end, he/she still gets the same content. From this
perspective, both experience ³could be² very similar.

However, this use case is rather limited and not applicable to many
applications. This is why I said ³could be². Also, both Cameron and I agree
that this is easier to implement IPv6-only on mobile network than on fixed
network because mobile operators have more control over the devices and
apps. IMHO, it will take longer time for fixed network operators to support
NAT64 only solution in the network.

On 8/25/10 9:41 AM, "huang cancan" <[email-masked]> wrote:

> well, I mean: why customer experience of IPv4-only + NAT444 could be the same
> as IPv6-only + NAT64?
> 
> On Wed, Aug 25, 2010 at 9:24 PM, Yiu L. Lee <[email-masked]> wrote:
>> On 8/25/10 7:13 AM, "huang cancan" <[email-masked]
>> <http://[email-masked]> > wrote:
>> 
>>> hi,Yiu:
>>>   As you mentioned below:
>>> On Sat, Aug 21, 2010 at 7:37 AM, Yiu L. Lee <[email-masked]
>>> <http://[email-masked]> > wrote:
>>>> 
>>>> [email-masked] <http://[email-masked]>

---

From: Fred Baker <[email-masked]>
Date: Wed, 25 Aug 2010 07:18:14 -0700

On Aug 25, 2010, at 7:05 AM, Yiu L. Lee wrote:

> From user’s perspective, do they care IPv4 or IPv6? Most don’t. For example: a casual web user wants to access his/her favorite IPv4-only website. If his web client and PC support IPv6 and on an IPv6-only network with NAT64, the web traffic will go through the NAT once. If his web client and PC support IPv4-only on an IPv4 network with NAT444, the web traffic will go through the NAT twice. In the end, he/she still gets the same content. From this perspective, both experience “could be” very similar. 

Yes and no. For the web, which is a client-server protocol, you are correct. Any protocol that requires the receiver to have a stable address at the time the sender decides to send to it - a server of any kind, or a peer-to-peer protocol like SIP - one has to have some kind of NAT-traversal mechanism to cross it - it pretty much becomes a service the user is sold or (think bittorrent) the application goes through some kind of hijinks to evade the service provider. For the user, the freedom of being able to use such applications without heaving to have them as a service has been one of the drivers of p2p applications.

> However, this use case is rather limited and not applicable to many applications. This is why I said “could be”. Also, both Cameron and I agree that this is easier to implement IPv6-only on mobile network than on fixed network because mobile operators have more control over the devices and apps. IMHO, it will take longer time for fixed network operators to support NAT64 only solution in the network.

CERNET/CERNET2 started from stateless translation, and is a fixed network. So I would be careful saying "never". But frankly, the solution for the fixed operators is not translation 6<->4; it is IPv6 deployment.

On 8/25/10 9:41 AM, "huang cancan" <[email-masked]> wrote:

>> well, I mean: why customer experience of IPv4-only + NAT444 could be the same as IPv6-only + NAT64?
>> 
>>> In order to deploy IPv6-only + NAT64, the client and network must talk IPv6. It also requires DNS64. These requirements are not needed for IPv4-only + NAT444. From the deployment point of view, they are very different technologies. 
>>> 
>>> 
>>> 
>>> On 8/25/10 7:13 AM, "huang cancan" <[email-masked] <http://[email-masked]> > wrote:
>>> 
>>>> hi,Yiu:
>>>>   As you mentioned below:
>>>> On Sat, Aug 21, 2010 at 7:37 AM, Yiu L. Lee <[email-masked] <http://[email-masked]> > wrote:
>>>>>

---

From: Alain Durand <[email-masked]>
Date: Wed, 25 Aug 2010 07:18:06 -0700

On Aug 25, 2010, at 10:05 AM, Yiu L. Lee wrote:

>From user’s perspective, do they care IPv4 or IPv6? Most don’t.

 It all depend if the user applications have been ported to support IPv6 or not.
If they have, yes, NAT64 or NAT44 makes little difference and most users won't care. Now, if those applications have NOT been
ported to IPv6 and only support IPv4, then there is a real difference: those may work in a NAT44 or NAT444 scenario but certainly
will not work in a NAT64 deployment.

Yes, I'm aware of the claim that in the wireless space, those apps can be controlled by the ISP and thus be ported to IPv6.
That may or may not be true for all apps running on the wireless device, but what about the apps running on a PC tethered
to the wireless device? The ISP has no control on those.

   - Alain.

---

From: "Victor Kuarsingh" <[email-masked]>
Date: Wed, 25 Aug 2010 10:32:05 -0400

Alain,

I agree with your comments.  In the mobile space, we have separated various types of endpoints and connection types and I would see the need to potentially deal with them separately.

Mobile devices that tether a PC/Notebook will likely have more IP connectivity demands then just a smartphone/handset which have a few applications.  Also, in mobile networks, things like 3G hubs/gateways and 3G-USB UE types will have very similar (if not the same) demands as traditional Wireline endpoints. I am hesitant on moving these connection types to IPv6-Only anytime soon on my network (dual stack options may be safer in the near term on those type of connections).

regards,

Victor K

-----Original Message-----
From: [email-masked] on behalf of Alain Durand
Sent: Wed 8/25/2010 10:18 AM
To: Yiu L. Lee
Cc: IPv6 v6ops; [email-masked]; Kurt Erik Lindqvist
Subject: Re: [v4tov6transition] draft-arkko-ipv6-transition-guidelines WGLC

On Aug 25, 2010, at 10:05 AM, Yiu L. Lee wrote:

>From user's perspective, do they care IPv4 or IPv6? Most don't.

   - Alain.

This e-mail (and attachment(s)) is confidential, proprietary, may be subject to copyright and legal privilege and no related rights are waived. If you are not the intended recipient or its agent, any review, dissemination, distribution or copying of this e-mail or any of its content is strictly prohibited and may be unlawful. All messages may be monitored as permitted by applicable law and regulations and our policies to protect our business. E-mails are not secure and you are deemed to have accepted any risk if you communicate with us by e-mail. If received in error, please notify us immediately and delete the e-mail (and any attachments) from any computer or any storage medium without printing a copy.

Ce courriel (ainsi que ses pièces jointes) est confidentiel, exclusif, et peut faire l’objet de droit d’auteur et de privilège juridique; aucun droit connexe n’est exclu. Si vous n’êtes pas le destinataire visé ou son représentant, toute étude, diffusion, transmission ou copie de ce courriel en tout ou en partie, est strictement interdite et peut être illégale. Tous les messages peuvent être surveillés, selon les lois et règlements applicables et les politiques de protection de notre entreprise. Les courriels ne sont pas sécurisés et vous êtes réputés avoir accepté tous les risques qui y sont liés si vous choisissez de communiquer avec nous par ce moyen. Si vous avez reçu ce message par erreur, veuillez nous en aviser immédiatement et supprimer ce courriel (ainsi que toutes ses pièces jointes) de tout ordinateur ou support de données sans en imprimer une copie.

---

From: Alain Durand <[email-masked]>
Date: Wed, 25 Aug 2010 07:49:19 -0700

Victor,

I agree with you. More, what would an IPv6-only network bring you?
In the end, the number of IP addresses needed in the NAT pool is the same for NAT44 and NAT64.
The real difference between the two technology is how are packets transported between the customer node
and the NAT. If this transport is v6, you have NAT64, if the transport is v4, you have NAT44...

Now, I hear the argument that deploying a v6 only network reduces the need for IPv4 addresses, as you do not have
to maintain an inefficient IPv4 addressing/routing plan... This is true. However, you do not have to limit yourself
to offering an IPv6 service on an IPv6-only network. You can create an IPv4 overlay, just like people build
production-quality IPv6 overlay on top of an IPv4-only network with 6rd. If you build that, you get the advantage of
both approach: reducing the network complexity/IPv4 inefficiency that NAT64 gives you and you keep serving
IPv4 to users whose applications are not yet ported to v6, just with a NAT44 solution.

    - Alain.

On Aug 25, 2010, at 10:32 AM, Victor Kuarsingh wrote:

> <ATT00001..txt>

---

From: "Yiu L. Lee" <[email-masked]>
Date: Wed, 25 Aug 2010 11:00:45 -0400

e2e IPv6 is the goal, nobody argues with it. However, China Telecom said
they would put 100+ million customers in the next 3 years. Obviously neither
they would get 100+ million public IPv4 addresses nor all the services in
the world would be IPv6 ready. Yes 6->4 may not be an immediate problem we
try to solve, but IPv4 exhaustion problem is immediate. I guess we are all
here to find out the real problems and give guidelines to solve the IPv4
exhaustion problem and deploy IPv6 in parallel.

Yiu

On 8/25/10 10:49 AM, "David Meyer" <[email-masked]> wrote:

> 
> 
>> CERNET/CERNET2 started from stateless translation, and is a fixed network. So
>> I would be careful saying "never". But frankly, the solution for the fixed
>> operators is not translation 6<->4; it is IPv6 deployment.
> 
> I have to agree with Fred here. While there may be advantages to
> PT in some cases, native IPv6 deployment has the advantage of
> preserving end-to-end (choose your definition of e2e), among others. 
> 
> 
> Dave
> 
>  
> 
>

---

From: Randy Bush <[email-masked]>
Date: Thu, 26 Aug 2010 00:25:20 +0900

> the solution for the fixed operators is not translation 6<->4; it is
> IPv6 deployment.

i suspect we do not disagree, but just to clarify.

fixed operators (in the non-wireless-phone sense) need to support home,
enterprise, etc. customers who will have both ipv4 and, we hope, ipv6
needs for a while.  so we need to deploy ipv6 *along side* ipv4, i.e.
dual stack.  stateless translation tools do not scale or perform well at
isp backbone scale.

our dual stack edge customers will use our dual stack backbones in a
simple fashion, no impedance matching needed.  the ipv6-only customer
will need nat64/dns64 to reach legacy ipv4-only destinations.

the ipv4-only customer will use ______ to reach ipv6-only destinations?

randy

---

From: Fred Baker <[email-masked]>
Date: Wed, 25 Aug 2010 08:30:24 -0700

> the ipv4-only customer will use ______ to reach ipv6-only destinations?

that of course would have to be stateless translation or ds-lite.

---

From: Alain Durand <[email-masked]>
Date: Wed, 25 Aug 2010 08:42:02 -0700

On Aug 25, 2010, at 11:30 AM, Fred Baker wrote:

> that of course would have to be stateless translation or ds-lite

Wrong direction...  DS-lite would enable a customer that is physically connected to a v6-only network to contact v4 nodes using his v4 apps.
Think more 6rd in that case to make that customer v6 capable or some variation on NAT46. See the draft I wrote with Christian Voght for that.

  - Alain.

---

From: Alain Durand <[email-masked]>
Date: Wed, 25 Aug 2010 08:38:24 -0700

On Aug 25, 2010, at 11:25 AM, Randy Bush wrote:

Use v4 to reach v4, use v6 to reach v6. No impedance mismatch, that, I understand.

Now, what is the reality of a **business** customer that does not have any IPv4 legacy application that needs to communicate to the outside (regardless of the outside being v4 or v6)?
Are we talking about an hypothetical case here or can we point out to a real example?
Because until such a customer really shows up, one can question the business case to offer an IPv6-only service.

Note: see my previous point, an ISP can deploy v4 as an overlay service on top of a v6-only physical network.

   - Alain.

---

From: Victor Kuarsingh <[email-masked]>
Date: Wed, 25 Aug 2010 11:49:03 -0400

Randy,

A clarification on the clarification,

>the ipv4-only customer will use ______ to reach ipv6-only destinations?

If what we mean here is the the operator only provided an IPv4 address to a
IPv6-capable device, then would tunneling not be an option here (i.e. 6RD,
6to4, Teredo)

If what we mean here is that the end device is addressed with IPv4-only and
is also IPv4-only-capable (i.e. XP without v6 stack enabled), then this is
not longer just a network connectivity issue.  We are now looking at how to
make IPv6 content (for example) available to IPv4 endpoints (proxy? NAT46
[scary?], Other mechanisms?).

Regards,

Victor K

---

From: "Yiu L. Lee" <[email-masked]>
Date: Wed, 25 Aug 2010 12:03:19 -0400

Hi Dave,

Well, I can¹t imagine an operator can launch an IPv6-only service with NAT64
to its customers in the next 3 years even the projection of growth is 10^8.
The roadblock is the legacy IPv4-only hosts (TV, xbox, PS3, WinXP, etc) in
customer¹s homes.

Yiu

On 8/25/10 11:09 AM, "David Meyer" <[email-masked]> wrote:

> Yiu,
> 
> On Wed, Aug 25, 2010 at 8:00 AM, Yiu L. Lee <[email-masked]> wrote:
>> e2e IPv6 is the goal, nobody argues with it. However, China Telecom said they
>> would put 100+ million customers in the next 3 years. Obviously neither they
>> would get 100+ million public IPv4 addresses nor all the services in the
>> world would be IPv6 ready. Yes 6->4 may not be an immediate problem we try to
>> solve, but IPv4 exhaustion problem is immediate. I guess we are all here to
>> find out the real problems and give guidelines to solve the IPv4 exhaustion
>> problem and deploy IPv6 in parallel.
>> 
> 
> Sure, and this seems like exactly the use case where you might
> need PT (6to4), since as you say, you need IPv6 to address the 
> 10^8 hosts but those hosts will want to talk to some non-zero
> number of IPv4 services.
> 
> Dave
> 
> 
>  
> 
>

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 25 Aug 2010 09:04:16 -0700

> exhaustion problem and deploy IPv6 in parallel.
 +1

For me, the problem is uniquely numbering a very large number of NEW
(m2m, mobile web, current BOGON mess, current n*RFC1918 mess...) hosts
given that IPv4 (public and private), for all intents and purposes, is
strategically (think current planning cycle) exhausted.

My belief is that the reality of edge growth (especially in mobile)
will force IPv6 deployments instead of counter-productive NAT444 and
RFC1918 version 2.  IPv6-only edge deployments will force NAT64 (more
in mobile) and DSlite (more in fixed).   The obvious disadvantages of
DSlite and NAT64 will encourage all parties involved (users, SP,
content) to earnestly TRANSITION to IPv6.  And, hopefully, NAT64 and
DSlite will only be a crutch for the long-tail.  For my users in the
USA, that fact that Facebook and Google / Youtube are already IPv6
make my last statement very close to being true today.

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 25 Aug 2010 09:10:13 -0700

On Wed, Aug 25, 2010 at 9:03 AM, Yiu L. Lee <[email-masked]> wrote:
> Hi Dave,
>
> Well, I can’t imagine an operator can launch an IPv6-only service with NAT64
> customer’s homes.

T-Mobile USA will launch IPv6-only + NAT64 in the next ~12 months for
a controlled set of new handsets models directed at consumers.

The service is up and running today and you can try it if you like at
http://groups.google.com/group/tmoipv6beta

I have been using IPv6-only + NAT64 for the past 6 months, no major
issues.  ~99% of apps work (thank you IP version agnostic API / SDK),
content works (very few IPv4 literals), .... It's really not the
problem that many may think it is .... especially if you are a mobile
operator.  For mobile, LSN is not a new and neither is RFC1918
exhaust.

Regards,

Cameron

---

From: "Yiu L. Lee" <[email-masked]>
Date: Wed, 25 Aug 2010 12:23:34 -0400

> make my last statement very close to being true today.

This transition period reminds me the days when Microsoft migrated from DOS
kernel to the NT kernel. When MS started the program, they provided a
transition technology called Win9x. Win9x uses the DOS kernel and gives
access to the old DOS programs and at the same time provides the new APIs to
build the apps that can run on the new NT kernel.

I see NAT64 and DS-lite are like Win9x technology. After few years, most
people saw the benefits of the new kernel and most developers found it
expensive to build/support two code streams for the same application.
Eventually, almost every Windows user and developer migrated to 2000, XP,
Vista, 7, etc. I hope IPv6 will happen the same way.

---

From: Fred Baker <[email-masked]>
Date: Wed, 25 Aug 2010 09:25:58 -0700

On Aug 25, 2010, at 8:00 AM, Yiu L. Lee wrote:

> e2e IPv6 is the goal, nobody argues with it. However, China Telecom said they would put 100+ million customers in the next 3 years. Obviously neither they would get 100+ million public IPv4 addresses nor all the services in the world would be IPv6 ready. Yes 6->4 may not be an immediate problem we try to solve, but IPv4 exhaustion problem is immediate. I guess we are all here to find out the real problems and give guidelines to solve the IPv4 exhaustion problem and deploy IPv6 in parallel.

Yes. From my admittedly-narrow perspective, it's primarily about turning on IPv6; you're not going to "solve" IPv4 exhaustion - it's not going to somehow become less exhausted. So if I may rephrase; it's about how to keep your IPv4 business running while you deploy IPv6. If you have an IPv4 network now, I would add "in your IPv4 network". If you have a green field, we built the translation technology in behave and it is now available from at least one vendor, and we have tunneling capabilities. What I find a lot of is people letting the "how will I access IPv4" question get in the way of deploying IPv6.

It brings to my mind a joke common in the US that may not be in China. I googled to find the canonical image, and mostly found US political humor. So I'll describe it. The picture shows either a person walking through a swamp and therefore waist-deep or chest-deep in water, or (funnier version) someone climbing a small tree in a swamp, desperately trying to get away from what is below. Caption: "when you're up to your ass in alligators (or snakes), it's hard to remember that you set out to drain the swamp". Based on the image, you will find Americans frequently talk about solving a big problem in terms of "draining the swamp".

In this case, "draining the swamp" is IPv6 deployment. At the point where we have universal deployment, this entire discussion will seem to have been a little pointless. Right now, the pressures of IPv4 access can seem overwhelming. 

The point of the joke is an object lesson in problem-solving. Yes, alligators and snakes are a problem, and have to be dealt with. If you let the issues consume you, that's all that will happen - you will be caught in the middle in perpetuity. If you focus on the objective, which is solving the "big problem", in this case IPv6 deployment, in time you will find that you have also solved the other. So yes, deal with what you have to, but don't let yourself be distracted from the real problem at hand. In this case, deal with IPv4 of course, but don't let that concern slow you down in deploying IPv6.

If you have an existing IPv4 network, Free.FR deployed an IPv6 service in their existing IPv4 network using 6rd with a team of a couple of people and a month's time if I have the story straight. That involved almost no actual native IPv6; 6rd is an IPv6/IPv4 tunnel infrastructure. But it allowed them to provide both IPv4 and IPv6 *services* to their customers while they took time to think about what they wanted to do natively. They can change their network under the hood, so to speak, an their own schedule.

Changing the network under the hood - that is the process hardware and software audit and upgrade, proving out configurations, and applying them where needed. No intention to trivialize, but if one can separate "delivery of the service" from "deployment of the technology", it might make the road a little easier.

Comcast has been a proponent of ds-lite. In this some portion of the network (at least one router or one link, but I should think more in practice) is converted to IPv6-only, and IPv4/IPv6 tunneling is used to carry IPv4 over that infrastructure to an IPv4/IPv4 NAT. IPv4 service is provided by tunnel while IPv6 is deployed natively. 3GPP has expressed interest in this approach, and specifically gateway-initiated ds-lite; in green field networks, several carriers (T-Mobile and Sprint that I know of, and I know of more that have talked about it) have deployed IPv6-only and used some form of tunnel infrastructure to provide IPv4 access, again through IPv4/IPv4 NAT.

The number of wireline networks that have literally turned up IPv6 within their existing IPv4 networks is pretty large. Many of them are on this list - Randy's comment a moment ago epitomizes their viewpoint. I don't think any of them would describe it as "without challenges", but I do get a lot of them quizzically wondering what the question here is. "So you have IPv4 access to IPv4 systems, and you have IPv6 access to IPv6 systems. Your point is what precisely?" Comments I get suggest that solutions like 6to4 and ISATAP are interesting ways to prototype the service, but if you need to do a build-out, they are science fair projects by comparison, primarily useful for testing IPv6 applications in a pre-IPv6 network.

And yes, CERNET's case demonstrates that stateless translation between an IPv4-only infrastructure and an IPv6-only infrastructure in fact works.

If it were my network to deploy in - and yes, this is the advice I am giving in my own shop - I think there are solutions on the table that have been shown to work. I would say "Pick one and do it". The hardest step in any journey is the first one. Take it, and you're that much closer to the destination.

---

From: Fred Baker <[email-masked]>
Date: Wed, 25 Aug 2010 09:29:46 -0700

> Vista, 7, etc. I hope IPv6 will happen the same way.

That is exactly the intention of each of these so-called "transition" technologies. They are in fact not for the purpose of transition, they are for the purpose of coexistence. But at the point that coexistence is no longer an issue - when either you have a dual stack deployment and can happily talk with either or when the vast majority of the network is in fact capable of using IPv6 end to end and IPv4 is therefore less of an issue - I expect they will be lost in the dust of time.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 26 Aug 2010 11:07:20 +1200

> same as IPv6-only + NAT64?

There are application scenarios that will work through a single layer
of NAT and fail through a double layer of NAT. I would have thought
this would have considerable impact on customer experience.

There are other negative impacts on content providers too, that were
discussed in a bar BOF in Anaheim.

   Brian

---

From: "Hui Deng" <[email-masked]>
Date: Thu, 26 Aug 2010 09:05:46 +0800

In that case, does win9x, dos, and NT need to talk each other?

-Hui

> [mailto:[email-masked]] On Behalf Of Yiu L. Lee
> Sent: Thursday, August 26, 2010 12:24 AM
> To: Cameron Byrne
> Cc: David Meyer; IPv6 v6ops; Kurt Erik Lindqvist;

---

From: David Meyer <[email-masked]>
Date: Wed, 25 Aug 2010 07:49:03 -0700

CERNET/CERNET2 started from stateless translation, and is a fixed network.
> So I would be careful saying "never". But frankly, the solution for the
> fixed operators is not translation 6<->4; it is IPv6 deployment.
>

Dave

---

From: David Meyer <[email-masked]>
Date: Wed, 25 Aug 2010 08:09:04 -0700

Yiu,

Dave

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 25 Aug 2010 12:43:54 -0700 (PDT)

----- Original Message ----
> From: Cameron Byrne <[email-masked]>
> To: Yiu L. Lee <[email-masked]>
> Cc: David Meyer <[email-masked]>; Erik Lindqvist <[email-masked]>; IPv6 
>v6ops <[email-masked]>; [email-masked]; [email-masked]
> Sent: Wed, August 25, 2010 11:10:13 AM

This is good news indeed and shows some real good progress.
I tried my IPhone 4 on v6only AP in Maastrict and it did not work, 
I think that contrary to what I hear, IPhone 4 does not seem to support IPv6.

Regards,

Behcet

---

From: Leo Vegoda <[email-masked]>
Date: Wed, 25 Aug 2010 14:54:08 -0700

On 25 Aug 2010, at 12:43, Behcet Sarikaya wrote:

[...]

> I think that contrary to what I hear, IPhone 4 does not seem to support IPv6.

It works in the sense that it will load web pages, etc... over IPv6. See:

http://twitpic.com/2i50fj

I suspect it relies on DHCP for DNS resolver configuration though and so fails to work for most purposes in IPv6-only at the moment.

Regards,

Leo

---

From: Joel Jaeggli <[email-masked]>
Date: Wed, 25 Aug 2010 22:44:18 -0700

> the ipv4-only customer will use ______ to reach ipv6-only destinations?

prayer.

you're back to the typical problem, you make a query, you get back only
a aaaa record, so you're dead.

since the likelyhood of you changing the v4 only customer's stack is
limited you're stuck with alg's, and presumably only for a limited
subset of applications.

---

From: Joel Jaeggli <[email-masked]>
Date: Wed, 25 Aug 2010 23:46:39 -0700

> I think that contrary to what I hear, IPhone 4 does not seem to support IPv6.

A lot of consumer oriented devices continue to operate under the
assumption that if they were unable to dhcp v4 that they should try
another available network. That's not a problem from the cellular
operator's vantage point, but if you happen to be planning an ipv6 only
wireless lan you should take it under advisement.

---

From: Rémi Després <[email-masked]>
Date: Fri, 27 Aug 2010 18:43:53 +0200

Le 25 août 2010 à 18:25, Fred Baker a écrit :
> ...
> If you have an existing IPv4 network, Free.FR deployed an IPv6 service in their existing IPv4 network using 6rd with a team of a couple of people and a month's time if I have the story straight.

Not in a month's time, to be accurate, but still in only 5 weeks! 
IMHO, everyone involved in IPv6 deployment should be interested in this story.
For more details:
- tools.ietf.org/html/rfc5569 
- www.ripe.net/ripe/meetings/ripe-58/content/presentations/ipv6-free
 
Regards,
RD

> That involved almost no actual native IPv6; 6rd is an IPv6/IPv4 tunnel infrastructure. But it allowed them to provide both IPv4 and IPv6 *services* to their customers while they took time to think about what they wanted to do natively. They can change their network under the hood, so to speak, an their own schedule.
>

---

From: Ed Jankiewicz <[email-masked]>
Date: Fri, 27 Aug 2010 15:16:40 -0400

Not an endorsement, merely a data point:  I am currently using 6rd for 
IPv6 access as part of a trial deployment by Comcast.  The shipped me 
the 6rd-enhanced router, and it was plug-and-play.  If not for the 
dancing turtle (and Google and Facebook via IPv6) I would hardly notice 
a difference from my baseline service.  WFM, YMMV.

This is a methodology to consider if modification of CPE is reasonable 
in your network.  If not, there are variants being discussed that will 
work with unmodified CPE.

http://tools.ietf.org/html/rfc5569
http://tools.ietf.org/html/rfc5969
http://tools.ietf.org/html/draft-despres-softwire-6rdplus-00
http://tools.ietf.org/html/draft-lee-softwire-6rd-udp-02

Ed J

---

From: "Yiu L. Lee" <[email-masked]>
Date: Fri, 27 Aug 2010 15:18:09 -0400

I am glad that you are a happy 6rd user :-)

On 8/27/10 3:16 PM, "Ed Jankiewicz" <[email-masked]> wrote:

>>> If you have an existing IPv4 network, Free.FR deployed an IPv6 service in
>>> their existing IPv4 network using 6rd with a team of a couple of people and
>>> a month's time if I have the story straight.
>>> That involved almost no actual native IPv6; 6rd is an IPv6/IPv4 tunnel
>>> infrastructure. But it allowed them to provide both IPv4 and IPv6 *services*
>>> to their customers while they took time to think about what they wanted to
>>> do natively. They can change their network under the hood, so to speak, an
>>> their own schedule.
>>> 
>>> Changing the network under the hood - that is the process hardware and
>>> software audit and upgrade, proving out configurations, and applying them
>>> where needed. No intention to trivialize, but if one can separate "delivery
>>> of the service" from "deployment of the technology", it might make the road
>>> a little easier.
>>> ...
>>

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 28 Aug 2010 08:55:37 +1200

Ed,

To your list of alternatives, please add
http://tools.ietf.org/html/draft-carpenter-softwire-sample

Regards
   Brian Carpenter

On 2010-08-28 07:16, Ed Jankiewicz wrote:
>>> If you have an existing IPv4 network, Free.FR deployed an IPv6
>>> service in their existing IPv4 network using 6rd with a team of a
>>> couple of people and a month's time if I have the story straight.
>>> That involved almost no actual native IPv6; 6rd is an IPv6/IPv4
>>> tunnel infrastructure. But it allowed them to provide both IPv4 and
>>> IPv6 *services* to their customers while they took time to think
>>> about what they wanted to do natively. They can change their network
>>> under the hood, so to speak, an their own schedule.
>>>
>>> Changing the network under the hood - that is the process hardware
>>> and software audit and upgrade, proving out configurations, and
>>> applying them where needed. No intention to trivialize, but if one
>>> can separate "delivery of the service" from "deployment of the
>>> technology", it might make the road a little easier.
>>> ...
>>

---

From: Ed Jankiewicz <[email-masked]>
Date: Fri, 27 Aug 2010 17:37:48 -0400

As I said, that comment was just one data point; there are a lot of 
proposals and alternatives and I'm sure we are all swamped.  I am 
willing to try to collate all the docs floating around the topic into a 
comprehensive (eventually) annotated bibliography for this group to 
consider.  This should help authors find each other, avoid duplication 
and cite related work.

I am accepting any and all suggestions and pointers.  Please reply on 
this thread, either just directly to me, or to the 
[email-masked] if it might be of interest to all.

Internet-Drafts, RFCs, other publications and websites on topics of 
interest:
transition problem statements
network operator experience, implementation reports
experiments, trials and prototypes
vendor/operator white papers, how-to, FAQs
coexistence and transition tools
and anything that you think is relevant

Thanks
Ed J.

---

From: Olivier MJ Crepin-Leblond <[email-masked]>
Date: Sat, 28 Aug 2010 00:21:03 +0200

> [email-masked] if it might be of interest to all. 

In which case, you might be interested in a presentation I sometimes
make with potential clients ipv6-related clients:

http://www.slideshare.net/ocl999/suggestion-for-an-ipv6-roll-out

Kind regards,

Olivier

-- 
Olivier MJ Crépin-Leblond, PhD
http://www.gih.com/ocl.html

---

From: "YangGL" <[email-masked]>
Date: Sun, 29 Aug 2010 08:40:55 +0800

Tests in my lab have proved that many popular applications cannot work on
IPv6-only network with NAT64, such as IM, P2P, games, and part of video. WEB
and part of mail (Outlook and Outlook express) are the only applications we
can find working properly with NAT64. But there are more than 50% traffic is
P2P, WEB traffic is less than 20% on CT’s network. I think it is not a good
news to NAT64.

Tests also prove that almost all of popular applications on Internet can
work on IPv4-only network with single level and double level NAT44, such as
WEB, mail, IM, P2P, games, video and etc.

NAT64 and NAT44 are similar in theory. But what make the difference of
application support? I think it should be timing. NAT44 appears ten years
ago. There are a few applications on internet at that time. Subsequent
applications, such as IM, P2P, were designed to work with NAT44. NAT64 come
after this popular applications, situation is totally different. If NAT64 is
deployed on commercial network now, CT’s network traffic will cut down 70%
immediately, and most applications will release a new version for IPv6-only
or NAT64 in the next one year. But it is not a good idea to providers.

Best regards,

Yang Guoliang

发件人: [email-masked]
[mailto:[email-masked]] 代表 Yiu L. Lee
发送时间: 2010年8月25日 22:05
收件人: huang cancan
抄送: Kurt Erik Lindqvist; IPv6 v6ops; [email-masked]
主题: Re: [v4tov6transition] draft-arkko-ipv6-transition-guidelines WGLC

>From user’s perspective, do they care IPv4 or IPv6? Most don’t. For
example: a casual web user wants to access his/her favorite IPv4-only
website. If his web client and PC support IPv6 and on an IPv6-only network
with NAT64, the web traffic will go through the NAT once. If his web client
and PC support IPv4-only on an IPv4 network with NAT444, the web traffic
will go through the NAT twice. In the end, he/she still gets the same
content. From this perspective, both experience “could be” very similar. 

However, this use case is rather limited and not applicable to many
applications. This is why I said “could be”. Also, both Cameron and I
agree that this is easier to implement IPv6-only on mobile network than on
fixed network because mobile operators have more control over the devices
and apps. IMHO, it will take longer time for fixed network operators to
support NAT64 only solution in the network.

On Wed, Aug 25, 2010 at 9:24 PM, Yiu L. Lee <[email-masked]>
wrote:

hi,Yiu:

Can-can Huang

---

From: "Yiu L. Lee" <[email-masked]>
Date: Sat, 28 Aug 2010 20:53:44 -0400

Hi Guoliang,

This result is expected. Like Can-Can, Alain, Fred and many others including
myself know it will take time for applications to support NAT64.  I agree if
*all* operators together to launch NAT64, this will give tremendous
pressures to application developers to upgrade the apps to support NAT64.
However, the reality is each operator has different plan and schedule,
customers will switch to another operators which can provide them seamless
access to the existing IPv4 applications.

I also encourage you to publish the experience for NAT444 and NAT64 in a
draft. I can work with you for the ds-lite tests. This is useful information
for operators to evaluate the existing transition techniques.

Again, thanks for taking the time to run the tests and share the info in the
list.

Yiu

On 8/28/10 8:40 PM, "YangGL" <[email-masked]> wrote:

> Tests also prove that almost all of popular applications on Internet can work
> on IPv4-only network with single level and double level NAT44, such as WEB,
> mail, IM, P2P, games, video and etc.
> application support? I think it should be timing. NAT44 appears ten years ago.
> There are a few applications on internet at that time. Subsequent
> immediately, and most applications will release a new version for IPv6-only or
> NAT64 in the next one year. But it is not a good idea to providers.
> 
>  
> Best regards,
> Yang Guoliang
>  
> 
> From user’s perspective, do they care IPv4 or IPv6? Most don’t. For example: a
> casual web user wants to access his/her favorite IPv4-only website. If his web
> client and PC support IPv6 and on an IPv6-only network with NAT64, the web
> traffic will go through the NAT once. If his web client and PC support
> IPv4-only on an IPv4 network with NAT444, the web traffic will go through the
> NAT twice. In the end, he/she still gets the same content. From this
> perspective, both experience “could be” very similar.
> 
> applications. This is why I said “could be”. Also, both Cameron and I agree
> network because mobile operators have more control over the devices and apps.
> IMHO, it will take longer time for fixed network operators to support NAT64
> only solution in the network.
> 
> 
but

---

From: "YangGL" <[email-masked]>
Date: Sun, 29 Aug 2010 08:56:47 +0800

I totally agree with this suggestion. The situation is different in China
telecom. CT is not just thinking, she is doing now. we need help.

Best regards,

Yang Guoliang

发件人: [email-masked]
[mailto:[email-masked]] 代表 Yiu L. Lee
发送时间: 2010年8月25日 23:01
收件人: David Meyer; Fred Baker
抄送: IPv6 v6ops; [email-masked]; Kurt Erik Lindqvist
主题: Re: [v4tov6transition] draft-arkko-ipv6-transition-guidelines WGLC

Yiu

Dave

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 29 Aug 2010 13:02:01 +1200

Hi Guoliang,

Very interesting. I think we need to have this dicussion on the
BEHAVE list first. Can you please send a message or draft there
with more details (which NAT64 implementation, exact system
config, what are the failure modes). Also for the failing
applications, compare with the pure IPv6 scenario as well as
the pure IPv4 scenario.

It's BEHAVE's job to fix the spec if it can be done.

Regards
   Brian Carpenter

On 2010-08-29 12:40, YangGL wrote:
> ------------------------------------------------------------------------
>

---

From: "YangGL" <[email-masked]>
Date: Sun, 29 Aug 2010 10:30:59 +0800

Welcome to work with us for DS-lite, it my pleasure!

Best regards,

Yang Guoliang

发件人: Yiu L. Lee [mailto:[email-masked]] 
发送时间: 2010年8月29日 8:54
收件人: YangGL; 'huang cancan'
抄送: 'Kurt Erik Lindqvist'; 'IPv6 v6ops'; [email-masked]
主题: Re: [v4tov6transition] draft-arkko-ipv6-transition-guidelines WGLC

Hi Guoliang,

Yiu

Best regards,
Yang Guoliang

 
 
Can-can Huang

---

From: "YangGL" <[email-masked]>
Date: Sun, 29 Aug 2010 10:35:47 +0800

Thank you! I am trying to write a detail report about our tests.

Best regards,
Yang Guoliang

-----邮件原件-----
发件人: Brian E Carpenter [mailto:[email-masked]] 
发送时间: 2010年8月29日 9:02
收件人: YangGL
抄送: 'Yiu L. Lee'; 'huang cancan'; 'IPv6 v6ops'; [email-masked]; 'Kurt Erik Lindqvist'
主题: Re: [v4tov6transition] draft-arkko-ipv6-transition-guidelines WGLC

Hi Guoliang,

Regards
   Brian Carpenter

---

From: Fred Baker <[email-masked]>
Date: Sat, 28 Aug 2010 23:08:58 -0700

</chair> <!-- v6ops -->
<author> <!-- draft-ietf-behave-v6v4-xlate -->

May I ask a question?

When you say you tested it with NAT64, what did you test with?

There are two modes for translation between IPv4 and IPv6. The stateful mode, described in draft-ietf-behave-v6v4-xlate-stateful, is essentially identical in function to IPv4/IPv4 NAT, and allows IPv6 systems to connect to IPv4 systems but not the reverse. The stateless mode, described in draft-ietf-behave-v6v4-xlate, allows connections to be initiated in either direction. The downside of the stateless mode is that it requires a direct mapping between an IPv4 and an IPv6 address. The are two parts of a common framework, use the same addressing plan, and the same DNS extension.

Are you running both modes, or only the stateful mode? If you are only running the stateful mode, that what you're reporting is what we have been saying for some time it will behave like.

http://datatracker.ietf.org/doc/draft-ietf-behave-address-format
http://tools.ietf.org/html/draft-ietf-behave-address-format
  "IPv6 Addressing of IPv4/IPv6 Translators", Congxiao Bao, Christian
  Huitema, Marcelo Bagnulo, Mohammed Boucadair, Xing Li, 15-Aug-10,
  <draft-ietf-behave-address-format-10.txt>

http://datatracker.ietf.org/doc/draft-ietf-behave-dns64
http://tools.ietf.org/html/draft-ietf-behave-dns64
  "DNS64: DNS extensions for Network Address Translation from IPv6 Clients
  to IPv4 Servers", Marcelo Bagnulo, Andrew Sullivan, Philip Matthews,
  Iljitsch van Beijnum, 5-Jul-10, <draft-ietf-behave-dns64-10.txt>

http://datatracker.ietf.org/doc/draft-ietf-behave-v6v4-framework
http://tools.ietf.org/html/draft-ietf-behave-v6v4-framework
  "Framework for IPv4/IPv6 Translation", Fred Baker, Xing Li, Congxiao
  Bao, Kevin Yin, 17-Aug-10, <draft-ietf-behave-v6v4-framework-10.txt>

http://datatracker.ietf.org/doc/draft-ietf-behave-v6v4-xlate
http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate
  "IP/ICMP Translation Algorithm", Xing Li, Congxiao Bao, Fred Baker,
  22-Aug-10, <draft-ietf-behave-v6v4-xlate-22.txt>

http://datatracker.ietf.org/doc/draft-ietf-behave-v6v4-xlate-stateful
http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate-stateful
  "Stateful NAT64: Network Address and Protocol Translation from IPv6
  Clients to IPv4 Servers", Marcelo Bagnulo, Philip Matthews, Iljitsch van
  Beijnum, 12-Jul-10, <draft-ietf-behave-v6v4-xlate-stateful-12.txt>

On Aug 28, 2010, at 5:40 PM, YangGL wrote:

> Tests in my lab have proved that many popular applications cannot work on IPv6-only network with NAT64, such as IM, P2P, games, and part of video. WEB and part of mail (Outlook and Outlook express) are the only applications we can find working properly with NAT64. But there are more than 50% traffic is P2P, WEB traffic is less than 20% on CT’s network. I think it is not a good news to NAT64.
> Tests also prove that almost all of popular applications on Internet can work on IPv4-only network with single level and double level NAT44, such as WEB, mail, IM, P2P, games, video and etc.
> NAT64 and NAT44 are similar in theory. But what make the difference of application support? I think it should be timing. NAT44 appears ten years ago. There are a few applications on internet at that time. Subsequent applications, such as IM, P2P, were designed to work with NAT44. NAT64 come after this popular applications, situation is totally different. If NAT64 is deployed on commercial network now, CT’s network traffic will cut down 70% immediately, and most applications will release a new version for IPv6-only or NAT64 in the next one year. But it is not a good idea to providers.
>  
> Best regards,
> Yang Guoliang
>  
> 发件人: [email-masked] [mailto:[email-masked]] 代表 Yiu L. Lee
> 发送时间: 2010年8月25日 22:05
> 收件人: huang cancan

---

From: huang cancan <[email-masked]>
Date: Mon, 30 Aug 2010 17:04:04 +0800

Hi,Fred:
   We test the statful one and hadn't test the statless one, because there
is no commercial device supporting DIVI.

2010/8/29 Fred Baker <[email-masked]>

> There are two modes for translation between IPv4 and IPv6. The stateful
> mode, described in draft-ietf-behave-v6v4-xlate-stateful, is essentially
> identical in function to IPv4/IPv4 NAT, and allows IPv6 systems to connect
> to IPv4 systems but not the reverse. The stateless mode, described in
> draft-ietf-behave-v6v4-xlate, allows connections to be initiated in either
> direction. The downside of the stateless mode is that it requires a direct
> mapping between an IPv4 and an IPv6 address. The are two parts of a common
> framework, use the same addressing plan, and the same DNS extension.
>
> Are you running both modes, or only the stateful mode? If you are only
> running the stateful mode, that what you're reporting is what we have been
> saying for some time it will behave like.
>
> > 发件人: [email-masked] [mailto:
> [email-masked]] 代表 Yiu L. Lee
> > 发送时间: 2010年8月25日 22:05
> > 收件人: huang cancan
> > On 8/25/10 7:13 AM, "huang cancan" <[email-masked] <
> http://[email-masked]> > wrote:
> >
> > hi,Yiu:
> >   As you mentioned below:
> > On Sat, Aug 21, 2010 at 7:37 AM, Yiu L. Lee <[email-masked] <
> http://[email-masked]> > wrote:
> >

---

From: huang cancan <[email-masked]>
Date: Mon, 30 Aug 2010 17:26:26 +0800

Another reason why we don't test stateless NAT64 is that there are few
application clients support IPv6, we can only test web or mail applications
which are also OK with the stateful one.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 31 Aug 2010 10:38:10 +1200

Hi,

> which are also OK with the stateful one.

But you reported other applications failing. How can they fail with NAT64 if
they have no IPv6 support in the first place?

   Brian

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 30 Aug 2010 15:42:16 -0700

> P2P, WEB traffic is less than 20% on CT’s network. I think it is not a good

I agree, NAT64 is not great for fixed line operators today, but i am
sure someone has suggested DS-lite to you.

Mobile wireless in the USA is a different case, 90+% of my traffic is
Web (tcp 80 and 443) and Email (pop,smtp, imap ...).  And, 40+% of my
overall aggregate ISP bandwidth goes to content providers that have
substantial capability to deliver IPv6 content today (Google,
Facebook, ...).  As draft-arkko-ipv6-only-experience states, mobile
can reach near 100% functionality today with IPv6-only on the
handsets.  The expedience varies greatly between handset manufactures,
but the gap is closing quickly.  Most folks know Nokia is a leader in
IPv6, and now we see substantial IPv6 efforts from Android and Apple
(Windows phone 7?).

>From an access network perspective, i have found it is extremely
important to partner with content providers as well as applications
developers and have an open dialog about native IPv6 as well as how
transition mechanisms will impact the user experience.  In my real
world experience, the content providers take user experience very
seriously, and they know CGN is harmful and IPv6 is a near term
reality.  And, i have taken the wiki approach to fix IPv4 literals
http://groups.google.com/group/ipv4literals , at least the ones that
can be fixed as i encounter them in my real world pilot network.

I believe the point here, as someone else likely said, there is no one
size fits all.  Using a search engine, you can find enough general and
enough specific information to find what works best for you.  Review
it with your vendors, do labs, trials, pilots, betas .... learn,
repeat, deploy at small scale, learn, then deploy at large scale,
monitor, learn, fix ... probably need to do training in there
somewhere too.  From a technology evolution and process perspective,
there is nothing new with IPv6.

Finally, it is interesting you said that 50% of the traffic is P2P and
you are concerned P2P will not work with IPv6.  According to this
link, P2P traffic is driving IPv6 growth http://tinyurl.com/lkjwhq and
http://tinyurl.com/25ka5jp  From the operators that i have talked to,
rolling out IPv6 natively in the fixed-line environment reveals a
substantial amount of P2P  IPv6 traffic.  uTorrent is an IPv6
vanguard.  Others will follow if they have not already in making their
apps work with IPv6.

Once again, the knife cuts both ways. Some P2P applications will
thrive in IPv6 (seems obvious given e2e nature of things) while others
will be forced to evolve or be deprecated by their users.

Regards,

Cameron
=======
=======

---

From: huang cancan <[email-masked]>
Date: Tue, 31 Aug 2010 09:38:34 +0800

hi, Brian:
   Yes, we didn't test the applications with clients installed in people's
PC no matter the NAT64 is a stateful one or a stateless one.
    I think we have a little different understanding about the original
question:"why customer experience of IPv4-only + NAT444 could be the same as
IPv6-only + NAT64? Do you have any test data?" I asked this question for the
sake of making up our migration strategy.
    What we focus on is the customer experiences, so if now the clients
cannot support IPv6, we think the customer experience when we using NAT64 in
our network in the first phase is worse than using NAT444+IPv4 because most
clients supporting NAT444.
   And what you focus on is the NAT64, the technology itself, so you think
if there is no test on NAT64, we cannot draw the conclusion that NAT444 is
better than NAT64.
   By the way, we also think it NAT444+IPv4-only cannot solve the problem
ultimately, NAT444+IPv6 should be better in the first phase.

  Thanks.

On Tue, Aug 31, 2010 at 6:38 AM, Brian E Carpenter <
[email-masked]> wrote:

> agree
> >>> On Wed, Aug 25, 2010 at 9:24 PM, Yiu L. Lee <[email-masked]
> >
> >> wrote:
> >>> On Sat, Aug 21, 2010 at 7:37 AM, Yiu L. Lee <[email-masked]<
> >>> Life cycle of mobile equipments could be every 2-3 years, but life
> cycle
> >> of
> >>> there are technologies such as DS-lite and Softwire Mesh available to
> run
> >> a
> >>> experience of IPv4-only + NAT444 could be the same as IPv6-only +
> NAT64,
> >> but

---

From: "YangGL" <[email-masked]>
Date: Tue, 31 Aug 2010 10:27:10 +0800

Hi Fred,
You are really the dictionary of IPv6! Your mail always make me feel
difficult to answer, too many references to read, give me some time, I will
come back after reading those documents mentioned in your mail.

Best regards,
Yang Guoliang

</chair> <!-- v6ops -->

May I ask a question?

---

From: Tina TSOU <[email-masked]>
Date: Tue, 31 Aug 2010 11:12:58 +0800

Technically, these drafts are well written and very useful. It is really 
appreciated. Fred, would you explicitly point out the answers of the 
following questions from these drafts? Thanks.

1) There are some applications, server, clients don’t support IPv6. These 
situations will be met regardless of stateful or stateless NAT64. No one has 
right to request these applications must support IPv6 (Monocrat may have), 
but these applications have existed and been used for many people. In the 
migration to IPv6, if these users can’t use these service and applications, 
it will result in the losing of subscribers for operators, unless all the 
operators of the world support IPv6 at the same moment.

2) Some applications have supported NAT44 traversal maturely, but in a long 
period of time in the future these applications would unlikely to support 
NAT64’s traversal. If adopting NAT64, these applications would be impacted. 
No one has the right to request these applications must support NAT64 
traversal, so after the usage of NAT64, these application will conk out 
inevitably. Both stateful and stateless NAT64 have the same issues.

3) Some applications contain the senders’ IP address in the packet payload, 
even in the encrypted packet case. These will have problems when using 
NAT64. Since these applications are existing applications, no one has right 
to requesting stop using these applications. These issues will be 
encountered when using NAT64 (both stateful and stateless ones have the same 
problem).

4) No one has the right to force all the UE to support IPV6, therefore from 
the technology evolution point of view, we don't have to consider IPV4 only 
user actively visits IPv6 only service, but in the actual use people have to 
consider it, otherwise it may result in the subscriber losing. Yes, it is 
not NAT64.

5) For some P2P application, after using NAT64, IPv4 only peer is not able 
to actively scan the IPv6 only peer; some P2P applications don’t consider 
NAT64 traversal for the time being.

Again, these drafts are very practical drafts, any way.

B. R.
Tina

----- Original Message ----- 
From: "YangGL" <[email-masked]>
To: "'Fred Baker'" <[email-masked]>
Cc: "'Behave WG'" <[email-masked]>; "'Kurt Erik Lindqvist'" 
<[email-masked]>; "'IPv6 v6ops'" <[email-masked]>; 
<[email-masked]>
Sent: Tuesday, August 31, 2010 10:27 AM
Subject: Re: [v4tov6transition] draft-arkko-ipv6-transition-guidelines WGLC

---

From: Joel Jaeggli <[email-masked]>
Date: Mon, 30 Aug 2010 21:23:36 -0700

Just a few observations without the wg-cochair hat on.

On 8/30/10 8:12 PM, Tina TSOU wrote:
> 1) There are some applications, server, clients don’t support IPv6.
> These situations will be met regardless of stateful or stateless NAT64.
> No one has right to request these applications must support IPv6
> (Monocrat may have), but these applications have existed and been used
> for many people. In the migration to IPv6, if these users can’t use
> these service and applications, it will result in the losing of
> subscribers for operators, unless all the operators of the world support
> IPv6 at the same moment.

Legacy ipv4 only apps aren't going to support v6 period, it has nothing
to do with when operators support or don't support ipv6. legacy
applications do not become new again. see (3) for dicussion of rights.

> 2) Some applications have supported NAT44 traversal maturely, but in a
> long period of time in the future these applications would unlikely to
> support NAT64’s traversal. If adopting NAT64, these applications would
> be impacted. No one has the right to request these applications must
> support NAT64 traversal, so after the usage of NAT64, these application
> will conk out inevitably. Both stateful and stateless NAT64 have the
> same issues.

An application that supports nat64 traversal is fact a native ipv6
application that isn't dependent on layer violations for it's signaling
of among other things ip address port numbers or security bindings. You
sort of characterized this in (3).

> 3) Some applications contain the senders’ IP address in the packet
> payload, even in the encrypted packet case. These will have problems
> when using NAT64. Since these applications are existing applications, no
> one has right to requesting stop using these applications. These issues
> will be encountered when using NAT64 (both stateful and stateless ones
> have the same problem).

The word "right" is a challenge to me here. Supporting a protocol on a
network is a business decision(for example, when do I add ipv6 aaaa
records to a service in my network). It is is in the interests of
internet service providers to induce as little deliberate breakage into
the network as possible. As a content and services provider (which is
what I do) if I don't adhere to this axiom I get to look for a new job.

> 4) No one has the right to force all the UE to support IPV6, therefore
> from the technology evolution point of view, we don't have to consider
> IPV4 only user actively visits IPv6 only service, but in the actual use
> people have to consider it, otherwise it may result in the subscriber
> losing. Yes, it is not NAT64.

There is going to be a time where ipv4 only users cannot access a
resource because it only accessible via v6, in superficial cases this
happens all the time. It is in the interests of most if perhaps not all
network operators, application vendors and end users, to push the time
in which that occurs routinely, beyond the window in which ipv6
deployment largely occurs. That said it seems like that workarounds
associated with ipv4 support post-runout will result in a gradually less
usable ipv4 network, which is if anything and incentive against holding
out to the bitter end.

> 5) For some P2P application, after using NAT64, IPv4 only peer is not
> able to actively scan the IPv6 only peer; some P2P applications don’t
> consider NAT64 traversal for the time being.

p2p applications have a built-in assumption of the existence of usable
endpoint identifiers. To the extent that ipv4 identifiers become
progressively less usable, p2p applications will prefer ipv6, that will
require upgrade or substitution.

> Again, these drafts are very practical drafts, any way.

It is useful to understand what on a v6 native host is not going to work
well through a 6to4 gateway. It is not so useful to have an
existence-proof for problems with ipv4 only applications, given that we
have ipv4-only-hosts to support into the immediately forseeable future.
The assumption that I make with those devices be they embedded systems,
pc's, mobile phones, etc, Is that I have the luxury of zero stack change.

> ----- Original Message ----- From: "YangGL" <[email-masked]>
>>> > experience of IPv4-only + NAT444 could be the same as IPv6-only + >
>>> NAT64,
>> but
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
>

---

From: Rémi Després <[email-masked]>
Date: Tue, 31 Aug 2010 12:05:50 +0200

Hi Fred, hi Jari,

Sorry for the late answer.
1.
The main issue I see is the need for a better balance between dual stack throughout and IPv6 across IPv4 infrastructures as recommended approaches for rapid deployments.
The latter approach is more recent (with RFC 5569 and RFC 5969 issued in January and August 2010 respectively) but, as it proved to be the preferred one by a number of ISPs for their first deployment, it should be documented as such.
2.
Also, there appears a converging interest for 4rd, the reverse of 6rd for IPv4 connectivity across IPv6-only ISP infrastructures (draft-vautrin-softwire-4rd-00 and draft-despres-softwire-sam-01 sec. 3.2).
As it is a potential alternative or complement to DS-lite, that some ISPs can consider, and that at least one does consider on a confidential basis, it should IMHO be mentioned. (Of course it shouldn't be hidden that the specification is still much less advanced than that of DS-lite).      

Attached is a modified version of draft-06, in PDF and and in .doc, in  which I propose an example text to cover these points.

Regards,
RD