Subject: draft-arkko-ipv6-transition-guidelines WGLC

From: Fred Baker <[email-masked]>
Date: Sun, 15 Aug 2010 11:00:04 -0700

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: <[email-masked]>
Date: Tue, 17 Aug 2010 10:53:04 +0200

Dear authors,

The draft currently states the following:

"4.3.  IPv6-Only Core Network

   An emerging deployment model uses IPv6 as the dominant protocol at a

   service provider network, and tunnels IPv4 through this network in a

   manner converse to the one described in the previous section.  There

   are several motivations for choosing this deployment model:

   o  There may not be enough public or private IPv4 addresses to

      support network management functions in an end-to-end fashion,

      without segmenting the network into small parts with overlapping

      address space.

   o  IPv4 address sharing among subscribers may involve new address

      translation nodes within the service provider's network.  IPv6 can

      be used to reach these nodes.  Normal IPv4 routing is insufficient

      for this purpose, as the same addresses would be used in several

      parts of the network.

   o  It may be simpler for the service provider to employ a single-

      version network.

   The recommended tool for this model is Dual Stack Lite

   [I-D.ietf-softwire-dual-stack-lite].  Dual Stack Lite provides both

   relief for IPv4 address shortage and makes forward progress on IPv6

   deployment, by moving service provider networks and IPv4 traffic over

   IPv6.  Given this IPv6 connectivity, as a side-effect it becomes easy

   to provide IPv6 connectivity all the way to the end users."

DS-Lite as currently defined in I-D.ietf-softwire-dual-stack-lite cannot be used in an IPv6-only SP network unless it is located at the boundaries of that networks (but this may have some issues such as no optimal routing path for intra-domain communications). A detailed solution of the deployment of DS-Lite in IPv6-only domain is defined in http://tools.ietf.org/html/draft-boucadair-dslite-interco-v4v6-04.

Adding a reference to this I-D would be more appropriate.

Cheers,
Med

________________________________
De : [email-masked] [mailto:[email-masked]] De la part de Fred Baker
Envoyé : dimanche 15 août 2010 20:00
À : [email-masked]
Cc : [email-masked]; [email-masked]
Objet : draft-arkko-ipv6-transition-guidelines WGLC

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

---

From: Fred Baker <[email-masked]>
Date: Tue, 17 Aug 2010 09:10:22 -0700

Thanks for your comment. You are correct that there are some parameters that need to be true of a network for ds-lite to be used in it. I'm confused,though. Why would an individual submission that a working group has not adopted be a better reference for a technology than the working group draft? May I ask you to get the softwire working group chair to support your viewpoint?

---

From: <[email-masked]>
Date: Wed, 18 Aug 2010 08:11:12 +0200

Dear Fred,

My comment is technical and it is orthogonal to logistic issues (i.e., adoption of a WG document). DS-Lite as currently defined in the base softiwre document alone without any companion mechanism cannot fit the scenario you are describing in your draft. Nevertheless, this is the focus of the individual draft I mentioned in my earlier message. That I-D specifies new interfaces and lists several options for the deployment of DS-Lite in an IPv6-only domain while allowing for a stateless interconnection between the IPv6-only domain and adjacent IPv4 ones.

As for your question, we have requested to present the draft in the last IETF meeting, but unfortunately we didn't been allocated a slot. My co-author can complete if required. FWIW, attached the presentation my co-authors prepared for the Maastricht meeting.

Cheers,
Med

________________________________
De : Fred Baker [mailto:[email-masked]]
Envoyé : mardi 17 août 2010 18:10
À : BOUCADAIR Mohamed NCPI/NAD/TIP
Cc : [email-masked]; [email-masked]; [email-masked]; [email-masked]
Objet : Re: draft-arkko-ipv6-transition-guidelines WGLC

On Aug 17, 2010, at 1:53 AM, <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>> wrote:

Dear authors,

Cheers,
Med

________________________________
De : [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] De la part de Fred Baker
Envoyé : dimanche 15 août 2010 20:00
À : [email-masked]<mailto:[email-masked]>
Cc : [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Objet : draft-arkko-ipv6-transition-guidelines WGLC

---

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,
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
http://tinatsou.weebly.com/index.html

----- 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...
>
> 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
>> 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.
>>>>
>>>> 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?
>>>
>>> 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
>>>
>>>
>>>>
>>>> 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.
>>>>
>>>>
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG v1.4.9 (MingW32)
>>>
>>> iEYEARECAAYFAkxqFPIACgkQcrhTYfxyMkKR8ACeMWWs4R9yi1JO4VGrx5QrG0vV
>>> 1lwAn16RYKVoGzEw3zJc67IgdvBH/7t+
>>> =826C
>>> -----END PGP SIGNATURE-----
>>
>>
>>
>
> _______________________________________________
> v4tov6transition mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v4tov6transition
>

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

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?

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

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: 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: "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: 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: Cameron Byrne <[email-masked]>
Date: Wed, 18 Aug 2010 14:53:47 -0700

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

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.

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: "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: Cameron Byrne <[email-masked]>
Date: Wed, 18 Aug 2010 15:57:51 -0700

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.

Dear authors,

I remain troubled that we are still pushing dual-stack as the
preferred transition mechanism.  I think we should add more language
stating that IPv6-only + NAT64 is very viable for general use,
especially in mobile, a very high growth area for IP address usage.

Jari has already presented his finding, which i view as very positive,
here http://www.ietf.org/proceedings/78/slides/behave-6.pdf

I would like to see some of the content from his deck added to this
draft.  As it stands, the draft gives me the impression that IPv6-only
is only for niche deployments and futuristic sensor networks.  Today,
IPv6-only is a real solution that i have trials going on with, and i
believe it is very functional for most common users, more at
http://groups.google.com/group/tmoipv6beta

Also, unilateral sounds bad.  Makes me feel like IPv6-only is not a
cooperative or friendly path.  I would say "Pure IPv6" or "IPv6
end-state deployments" which require gateways to IPv4

IMHO, traditional dual-stack is not viable for transition.  There are
not incentives for me to dual stack at home, work, or while mobile.
Traditional dual-stack does not provide a better user experience and
it does not save me any IPv4 addresses.  Dual-stack + NAT44 may
eventually have some benefits if I can by-pass the NAT44 with native
IPv6.  Same can be said for DS-lite.  But, traditional dual-stack
(public IPv4 and IPv6) is a non-starter.  And the idealistic notion
that dual-stack leads to a future where eventually everything will go
IPv6 and we can just turn off IPv4 without anyone knowing stopped
being viable around 2005, transition time ran out and nobody deployed
it.  Without incentives (carrots, sticks, other ...) dual-stack will
remain a science experiment for those inclined to do so, not a real
solution for end users numbering.  The real solutions that real
network service providers are deploying are address sharing mechanisms
that favor IPv6 end to end (DS + NAT44, DS-lite, NAT64).  Anything
else does not have the appropriate market mechanisms (Bad CGN
experience, motivate IPv6 native content to avoid CGN, uniquely
numbered users for e2e multimedia) to engender change.

I believe the IETF needs to be much more forceful in pushing
IPv6-first solutions.  Straddling the fence with traditional
dual-stack in not a real solution and re-enforces the notion that "I
do not have to do anything with IPv6, since dual-stack people will
always have IPv4" or "IPv6-only is not ready".  If we embrace a more
aggressive IPv6 path (which is the reality of IPv4 exhaust), then we
begin to stimulate the Internet ecosystem to understand that IPv4 is
really not the best strategic investment for client to (server | cloud
| client) communications.

Regards,

Cameron

ps.  Even in the face of IPv4 exhaust *you* don't need to be worried
about IPv4 exhaust
http://www.pcpro.co.uk/realworld/360418/why-you-shouldnt-worry-about-ipv6-just-yet

---

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

I'd let Jari speak for himself, but he's gone for a couple of weeks.

> especially in mobile, a very high growth area for IP address usage.

I certainly tried to edit that in, in section 4.4. It does have issues, notably in dealing with refers (if the target system tells you to redirect your request to an IPv4 address, how do you handle that?). But yes, it is operationally useful in those networks that have deployed it.

Can I ask you to suggest text?

> here http://www.ietf.org/proceedings/78/slides/behave-6.pdf

Hmm. You might read http://tools.ietf.org/html/draft-arkko-ipv6-only-experience
  "Experiences from an IPv6-Only Network", Jari Arkko, Ari Keranen,
  12-Jul-10, <draft-arkko-ipv6-only-experience-01.txt>

which is Jari's write-up on his experience. In the deck you refer to, the key take-awways are on slide 4 and 10; there are some things that worked, and some things that really didn't. Jari, having tried IPv6-only, was pleased with what worked but troubled  by the things that didn't. Xing Li has also commented to me on issues that CERNET2 has.

> is only for niche deployments and futuristic sensor networks.

OK, no problem. I'll add the second recommendation on slide 10 of Jari's deck to the draft. Oops, I don't need to - it's already there.

> Today,

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

which is on its way to RFC-dom defines:

   IPv6-only:  An IPv6-only implementation, in this context, comprises
      an IPv6-enabled end system stack, applications directly or
      indirectly using that IPv6 stack, plus routing in the network.  It
      implies that two application instances are capable of
      communicating using IPv6, but not IPv4 - they have an IPv6 stack,
      addresses, and network support including routing in IPv6, but some
      element is missing that prevents communication with IPv4 hosts.

Would it be OK with you if I changed that to "IPv6-only deployment"?

> not incentives for me to dual stack at home, work, or while mobile.

That's interesting, given the number of networks that have followed that route. I wonder what other operators would say about that?

> | client) communications.

On that point I agree. That said, for the vast number of networks, the issue is not bringing up IPv6 where IPv4 isn't; the issue is bringing up IPv6 in the existing IPv4 network. Hence, in talks I give (ftp://ftpeng.cisco.com/fred/nav6tf/Fred_Recent_Talk.pdf being an example), I very explicitly tell my audience that the term "transition" implies turning something ON and turning something OFF, and I am simply talking about DEPLOYMENT, which involves turning something ON. I have no problem with IPv6-only networks apart from protocols like SMTP, HTTP, FTP, and so on that carry IP addresses at the application layer. If we could get those to use names instead of addresses, I would be right with you.

---

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.

> mailing lists that handle tactical issues.

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

> problem to be solve.

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

> 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: Brian E Carpenter <[email-masked]>
Date: Thu, 19 Aug 2010 11:47:36 +1200

On 2010-08-19 10:57, Cameron Byrne wrote:
...
> it.  

This, sadly, is true. The dual stack model assumed that IPv6
would get everyhwere before IPv4 exhaustion hit. Shame about
that. However, that does not preclude a model where an ISP
prefers to deploy dual stack routing and thereby ends up with
3 classes of customers
  - IPv4 legacy customers
  - dual stack customers
  - IPv6-only customers
Many ISPs might conclude that this was actually their best
option. Personally I think it's appropriate for the draft
to present this as the most obvious option, but probably
it should explicitly point out that the above three classes
of customers will exist as a result, and there will be
interoperability issues.

The draft says:

4.3.  IPv6-Only Core Network

   An emerging deployment model uses IPv6 as the dominant protocol

I don't think we should be *recommending* this choice, or
any other choice, but the word "emerging" makes it sound
risky. Maybe we could just say "Another depolyment model..."

    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: 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]>

> in the IETF even work or have current experience at network operators.

both ears and the tail!

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

where was that box of q-tips?

> not incentives for me to dual stack at home, work, or while mobile.

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.

randy

---

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

> 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: Cameron Byrne <[email-masked]>
Date: Wed, 18 Aug 2010 21:41:42 -0700

> I certainly tried to edit that in, in section 4.4. It does have issues, notably in dealing with refers (if the target system tells you to redirect your request to an IPv4 address, how do you handle…

Right, IPv4 literals are a problem for IPv6-only networks.  But, i am
trying to control the FUD that tends to steam up from this type of
issue as well as resolve the root cause issues.  To that end, i direct
you to http://groups.google.com/group/ipv4literals.  I have been
IPv6-only on mobile for 6 months and i have 2 known issues in the
catalog.  If you know of more, please help me catalog them so that
problems that can be fixed, get fixed.  I know there are problems that
cannot be fixed, but those applications will evolve to deal with IPv6
and IPv4 exhaust or fade away into brokeness.  Please, lets keep a
close eye on this IPv4 literal issue and make sure we wrap our
concerns in facts and use those facts to drive action.

> which is Jari's write-up on his experience. In the deck you refer to, the key take-awways are on slide 4 and 10; there are some things that worked, and some things that really didn't. Jari, having…

I am seeing a broad brush strokes here.  From Jari's slide deck, i see
a delta of 0.2% breakage between IPv4-only and IPv6+NAT64 for web.
That is the long tail.  I am willing to send that 0.2% an email and
tell them they need to fix their IPv4 referrals or move to IPv6 to
ensure reachability in 12 months when IPv6-only service appear in
earnest.  I agree that online games are an issue per Jari's report,
but my mobile customers don't really do that today on their phones.
It might also be relevant to say that when many ISPs add their
aggregate traffic to Facebook and Google together, it starts to look
like around 40% of their bits go to these 2 AS's..... and those 2 AS's
have strong IPv6 efforts today.... so they don't even go via NAT64.

> which is on its way to RFC-dom defines:

A great effort.  Thank you and the team.

> Would it be OK with you if I changed that to "IPv6-only deployment"?

That sounds better to me.

> That's interesting, given the number of networks that have followed that route. I wonder what other operators would say about that?

As in my note to Randy, i am just talking about end-nodes and access
network, and really only mobile.  Not many end-nodes and access
network are dual-stack.  Comcast is an outstanding example of going
dual-stack.  Nearly everyone else in the access space is not, hence
6RD.

> On that point I agree. That said, for the vast number of networks, the issue is not bringing up IPv6 where IPv4 isn't; the issue is bringing up IPv6 in the existing IPv4 network. Hence, in talks I…

Ok.  I know 2 IPv4 literal users, they are in the catalog.  Your above
statement makes me feel like you know of more, please share them at
http://groups.google.com/group/ipv4literals  IPv4 literals will not go
away on their own, but i feel like i have a good grasp on how IPv4
literals impact today's user experience, and it is negligible impact
(on mobile).  Amazon Video and mobile.nytimes.com may not think the
impact is negligible, but i have already made a good faith attempt to
educate and encourage them to resolve this issue before it becomes
negatively impactful for them.  Finally, customer know they have
options when viewing online video and news.  I know of one major IPv6
adopter that provides news and video over IPv6 today .... They are
sure to work well in an IPv6-only access network.

---

From: Randy Bush <[email-masked]>
Date: Thu, 19 Aug 2010 15:09:31 +0900

>> That's interesting, given the number of networks that have followed
>> that route. I wonder what other operators would say about that?
> network are dual-stack.

the core is moving more and more to dual-stack.  aside from issues as
are being discussed (overuse of link local for routing protocols, lack
of management support in v6, blah blah blah), it is not really hard.
much of the cost is in the back office.  that is, until we get big v6
traffic and find many of the routers move v6 on the slow path.  the 6502
makes such a great forwarding engine.

it is not clear to me that we can expect the edge to be dual-stack.  big
printers can get software upgrades to handle v6.  small v4-only printers
have low amortization value.  the nt, win95, winxp, ... folk can get
macs.  i admit to being a bit crass here:).  but really, when you build
a new large lan in 2003, do you really want to make it rfc 1918?

i suspect that, five years out, the edge will be bi-modal, a lot of
v4-only/1918 crap and some v6/nat64.  and then a bunch of disgusting
kludge to deal with cgns and other devil spawn.

> Comcast is an outstanding example of going dual-stack.

thank you john b!

> Nearly everyone else in the access space is not, hence 6RD.

from 10,000m, what is 6rd but a teredo/6to4 that colludes with the
provider who won't do real v6?  it's a cute hack, but a hack.  we have
spent 15 years on hacks to punch ipv6 through the recalcitrant.  now we
have moved to punching it through the cgn and other foot draggers.  i
find it hard to become enthused.

i think we should stop being reactive and get on the front of the
surfboard, focus on making ipv6 easy and attractive to deploy both on
the backbone and in the edge.  i look forward to the day when i can tell
an enterprise or backbone operator that they can enable ipv6 and not
have to retrain their noc (or it department), make minimal change to
their back end, make minimal change to management, make minimal change
to security policy and mechanisms, ...  that task is hard enough.

randy

---

From: Randy Bush <[email-masked]>
Date: Thu, 19 Aug 2010 15:17:16 +0900

> a new large lan in 2003, do you really want to make it rfc 1918?

s/2003/2013/  <sigh>

---

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

On Aug 18, 2010, at 11:09 PM, Randy Bush wrote:

> have low amortization value.  

My Canon MP620, a low-end all-in-one, came from the store with both.

---

From: Randy Bush <[email-masked]>
Date: Thu, 19 Aug 2010 15:38:02 +0900

> My Canon MP620, a low-end all-in-one, came from the store with both.

kerzactly!

my point is

  o weird edge (wireless etc) are agile and are or will move and will
    use weird kludges to get to the internet anyway.  at least they have
    stopped trying to be walled gardens

  o the provider core is becoming dual stack or ipv6 except for some
    recalcitrant broadband providers

  o there are some v4-only devices in home/enterprise which will have to
    depreciate.  but do not buy v4-only devices now with the plan that
    they will last more than a year or two at most.

and the job of the ietf is to make this <bleep>ing *easy*

randy

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 19 Aug 2010 07:47:15 -0700 (PDT)

Hi Cameron,

> numbered users for e2e multimedia) to engender change.

I agree but you need to convince 3GPP on this. If you read 23.975, they 
recommend dual-stack and that's it.

Regards,

Behcet

---

From: Cameron Byrne <[email-masked]>
Date: Thu, 19 Aug 2010 08:56:01 -0700

> recommend dual-stack and that's it.

I don't believe i need to convince the 3GPP of anything since they are
not directly involved in designing my network.  Granted, it is nice
when our ideas align, but the standards and gear i use to execute on
my IPv6-only UE plans are already solid and my reference beta
deployment is complete with 50+ IPv6-only paying customers.  So, while
the 3GPP is writing docs, i am deploying services.  It is worth noting
that IPv6-only is part of the 3GPP doc, but clearly the 3GPP world is
focused on dual-stack with IPv4 addresses that providers don't have
now and won't have in the future (private or public addresses).

Regarding this 3GPP document you referenced:

http://3gppprotocol.com/web_documents/23975-111-ipv6-migr-guide.pdf

I don't like the language in it and i don't believe it accurately
reflects the sentiment and agreement that was achieved at the
IETF-3GPP meeting in San Francisco.

http://www.3gpp.org/ftp/workshop/2010-03-01_IPv4-to-IPv6_with-IETF/Docs./IPW100060.zip

In the IPv6-only section, it seems to reference host based translation
which was not popular at the meeting. I know that the host based
translation supporters have a new draft ... but that does not change
my perspective nor the official record on how to move forward from the
joint meeting.

Que sera sera.

Cameron

---

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 08:58:27 -0400

Brian,

> risky. Maybe we could just say "Another depolyment model..."

We can certainly say that.

(But I do think that the four models in the document are things that we 
can recommend.)

Jari

---

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: Cameron Byrne <[email-masked]>
Date: Fri, 20 Aug 2010 06:56:48 -0700

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

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

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.

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.

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

Regards,

Cameron

ps.  Just for grins, i tried the once announced
http://www.ipv6.cisco.com/ and it works!  But, alas, it is IPv6-only
not dual stack!

---

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

> http://www.ipv6.cisco.com/ and it works!  But, alas, it is IPv6-only

Just a few more comments

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

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

I believe it is best not to state:
"
However,
some applications - notably http, ftp, SIP, and others - carry IP
addresses in the application layer and expect them to be useful to
their peers, which require care in handling.
"
it may be more accurate to state that:
"
Communications involving IPv4 referral, in particular IPv4-literals
within certain protocols and formats such at HTML, will fail when
passed to IPv6-only hosts since the host does not have an IPv4 address
to source the IPv4 communications or an IPv4 route.  Current
measurement for HTTP on the public internet show that literals break
0.2% of  the world wide web.
"

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.

---

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.

>> since it does not add anything new or, IMHO, good advice to people

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.

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

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.

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

>> transition but it does not recommend or articulate how to turn IPv4

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.

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

> 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?

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

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

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.

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.

-- 
Mikael Abrahamsson    email: [email-masked]

---

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: Brian E Carpenter <[email-masked]>
Date: Sat, 21 Aug 2010 10:07:37 +1200

On 2010-08-21 04:08, Cameron Byrne wrote:
...
> whitelist are more votes against DS.

Actually they are votes against *broken* DS at the subscriber end of
the wire - typically, that means a subscriber whose host is under
the illusion that it has IPv6 connectivity when it doesn't.

They are definitely not votes against ISPs that have done a proper
dual stack deployment, since their subscribers don't have illusory
connectivity.

Which means they are actually votes against ISPs that have *not*
deployed DS. We would definitely not be having this conversation
if all ISPs had deployed a dual stack backbone already.

You're completely correct that the draft should clearly define
where it's talking about an ISP core and where it's talking about
the access network.

    Brian

---

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:
>> bearers, 2x mobility events, 2x many things ...).  Yes, the costs change in
>> LTE .... LTE will not be mainstream before IPv4 Exhaust.
>

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.

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

---

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: Cameron Byrne <[email-masked]>
Date: Fri, 20 Aug 2010 16:45:59 -0700

On Fri, Aug 20, 2010 at 4:37 PM, Yiu L. Lee <[email-masked]> wrote:
> 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.
>

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.

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

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: Randy Bush <[email-masked]>
Date: Sat, 21 Aug 2010 13:11:03 +0900

> Actually they are votes

there are?  votes?  i thought we had discussions on the merits of
various engineering approaches.

---

From: Randy Bush <[email-masked]>
Date: Sat, 21 Aug 2010 14:04:00 +0900

> These aren't IETF votes, Randy. These are network operators voting
> with their hard-earned cash on how to deploy.

ahhh, sorry.  apologie to brian.

randy

---

From: Fred Baker <[email-masked]>
Date: Fri, 20 Aug 2010 22:01:22 -0700

> various engineering approaches.

These aren't IETF votes, Randy. These are network operators voting with their hard-earned cash on how to deploy.

There are of course those that are not deploying. There is not much to be said about them other than that.

People that are doing green field networks may be implementing IPv6-only. I have heard several mobile operators suggest it, and I know one that has. I know of one research network, CERNET2, that has also done so.

Those that have existing IPv4 networks, to my knowledge, are not first shutting down their IPv4 networks and then bringing up IPv6; they are bringing ip IPv6 in the IPv4 networks.

You would be a well-placed party to observe on this. What incidence have you seen of IPv6-only deployment, and what incidence have you seen of IPv6 being deployed in existing IPv4 networks?

---

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:24:56 -0700

> People that are doing green field networks may be implementing IPv6-only. I have heard several mobile operators suggest it, and I know one that has. I know of one research network, CERNET2, that ha…

FYI, FWIW, my IPv6-only service is deployed on a network that is not
greenfield.  More on that below.

> Those that have existing IPv4 networks, to my knowledge, are not first shutting down their IPv4 networks and then bringing up IPv6; they are bringing ip IPv6 in the IPv4 networks.

FYI, FWIW, i am also not shutting down IPv4.  My approach is IPv6-only
deployed one handset model at a time.... no disturbance to existing
install base.... no boiling of the ocean.

> You would be a well-placed party to observe on this. What incidence have you seen of IPv6-only deployment, and what incidence have you seen of IPv6 being deployed in existing IPv4 networks?

Agreed.  Randy is a well placed party :)

He made a very insightful and very correct statement here
http://ops.ietf.org/lists/v6ops/v6ops.2010/msg00978.html

Wireless is a weird edge, your normal recommendations and standard LAN
/ WAN logic does not really apply.

If you would like to take mobile networks into account, i strongly
recommend that you view Mobile section from the Google conference
https://sites.google.com/site/ipv6implementors/2010/agenda

What has been missing from our dialog is the fact that i have already
deployed IPv6-only edge (phones, not routers) nationwide in the USA
without a single national network MOP, ipv6 address on a production
router,  or router upgrade.  The radio networks is also oblivious to
IPv6 services.  All i had to do was deploy an anchor point in a lab
with an IPv6 ISP, tweak a few user profile settings, and the rest just
works.  Thank you 3GPP.

This is by virtue of the fact that the user's IP (v4 or v6) only
really lives on the handset and the mobility anchor (GGSN).  Once the
IP packet leaves the handset it is tunneled all around inside of IPv4
mobility tunnels until it reaches the Internet boarder of my network,
where it becomes a real IPv6 routed packet again.  So, literally, the
IPv6 packets are only ever exposed on the handset itself and on the
mobility anchor (GGSN) facing the Internet.  There are hundreds of
routers in between that are oblivious to the fact that IPv6 is
deployed because the mobility tunnels are all IPv4 on the outside...
and will stay that way ... since it is only the edge (phones, not
routers) that NEED IPv6 to grow *my* business.

Dual stack routers in my network don't matter, aside from my internet
peering.  That said, the handset can be provisioned as "non-unique
with my network" or BOGON IPv4, IPv6, or at 2x the *packet core* cost
with non-unique IPv4 addresses AND IPv6.

I hope this provides some clarity.  For mobile, it is not about the
"IP network".   IPv6 vs IPv4 vs DS is only about the handset and how
it instantiates its Internet communication on the mobility anchor.  It
is fundamentally different from a backbone ISP going to dual-stack
from IPv4, which is a smart path that all my upstream ISPs have done.

Regards,

Cameron

---

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: 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: Rémi Després <[email-masked]>
Date: Tue, 31 Aug 2010 18:06:45 +0200

Le 19 août 2010 à 08:09, Randy Bush a écrit :

> provider who won't do real v6?  it's a cute hack, but a hack.

Descending to 100m, one can see that, unlike Teredo and 6to4, 6rd provides native IPv6 prefixes to customer sites, unlike Teredo and 6to4:
- Hosts behind a 6rd CPE are on a dual-stack LAN, and can't determine whether the ISP network is dual stack throughout or 6rd.
- From 6rd sites, connectivity with other IPv6 native addresses is guaranteed, which is the case with neither Teredo nor 6to4.

You told me once that, for you, "hack" had no negative connotation.
Then, "cute hack" can nicely be taken positively, thanks ;-).

Cheers,
RD

PS: Note that I have absolutely no financial interest in any of its actual applications, just being proud of having originated a useful mechanism.

---

From: "Gunter Van de Velde (gvandeve)" <[email-masked]>
Date: Tue, 31 Aug 2010 18:31:34 +0200

Next to that... teredo and 6to4 are non-managed services, while 6rd is a managed service... big difference for the user experience.

http://tools.ietf.org/html/draft-vandevelde-v6ops-harmful-tunnels-01

G/

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rémi Després
Sent: Tuesday, August 31, 2010 6:07 PM
To: Randy Bush
Cc: Cameron Byrne; IPv6 v6ops
Subject: Re: draft-arkko-ipv6-transition-guidelines WGLC

Cheers,
RD

---

From: Mohacsi Janos <[email-masked]>
Date: Tue, 31 Aug 2010 18:53:28 +0200 (CEST)

> http://tools.ietf.org/html/draft-vandevelde-v6ops-harmful-tunnels-01

What do you mean about managed service? I think 6to4 and teredo can be 
managed....

Best Regards,
 		Janos Mohacsi

> Le 19 ao?t 2010 ? 08:09, Randy Bush a écrit :
>

---

From: "Gunter Van de Velde (gvandeve)" <[email-masked]>
Date: Tue, 31 Aug 2010 19:21:02 +0200

Can be mananaged... but... if you use 6to4, then do you know the person running the relays? Do you even know who is running the relays? And why should the people running the relays care about you if you are not there direct customer?

G/

-----Original Message-----
From: Mohacsi Janos [mailto:[email-masked]] 
Sent: Tuesday, August 31, 2010 6:53 PM
To: Gunter Van de Velde (gvandeve)
Cc: Rémi Després; Randy Bush; Cameron Byrne; IPv6 v6ops
Subject: RE: draft-arkko-ipv6-transition-guidelines WGLC

Best Regards,
 		Janos Mohacsi

---

From: Mohacsi Janos <[email-masked]>
Date: Tue, 31 Aug 2010 19:34:48 +0200 (CEST)

On Tue, 31 Aug 2010, Gunter Van de Velde (gvandeve) wrote:

> Can be mananaged... but... if you use 6to4, then do you know the person 
> running the relays? Do you even know who is running the relays? And why 
> should the people running the relays care about you if you are not there 
> direct customer?

If a provider is encouraging to use 6to4, it will provide 6to4 relay for 
their customers: announcing anycast 6to4 relay address to them (probably 
only for them). Provider is monitoring operational status of 6to4 relay, 
traffic volume etc. plus help debugging MTU problems... Yes I know, this 
is can be done only for outgoing direction.... But if every 6to4 relay 
provider would be doing the same....

For example I used to know who is running the 6to4 relay used by me...(me 
and network operation team).  For 1.5 years I don't care much about 6to4 
relay anymore since I am using native IPv6 both at home and at work.

Best Regards,
 	Janos Mohacsi

---

From: "Gunter Van de Velde (gvandeve)" <[email-masked]>
Date: Tue, 31 Aug 2010 19:38:48 +0200

The thing is... you can't control the return path... so its non-managed and one relies upon the good-will of other people to have a good behaving 6to4 relay.

It may work now, and I do know people being super happy with 6to4, but if there would be 10000 people using same relay, the service may be degraded if it is just a sponsored service with revenue... It is a result of business reality.

G/

-----Original Message-----
From: Mohacsi Janos [mailto:[email-masked]] 
Sent: Tuesday, August 31, 2010 7:35 PM
To: Gunter Van de Velde (gvandeve)
Cc: Rémi Després; Randy Bush; Cameron Byrne; IPv6 v6ops
Subject: RE: draft-arkko-ipv6-transition-guidelines WGLC

Best Regards,
 	Janos Mohacsi

---

From: Mohacsi Janos <[email-masked]>
Date: Tue, 31 Aug 2010 19:43:30 +0200 (CEST)

On Tue, 31 Aug 2010, Gunter Van de Velde (gvandeve) wrote:

> The thing is... you can't control the return path... so its non-managed 
> and one relies upon the good-will of other people to have a good 
> behaving 6to4 relay.

Yes I know as I wrote. But if every 6to4 relay operator cares about the 
service....

>
> It may work now, and I do know people being super happy with 6to4, but 
> if there would be 10000 people using same relay, the service may be 
> degraded if it is just a sponsored service with revenue... It is a 
> result of business reality.

Same for any relay. As you might notice you announce your 6to4 relay only 
for your customers.... And you monitor the operational status of your 6to4 
relay, if ther is a need you deploy more....

Best Regards,

Janos

---

From: Gert Doering <[email-masked]>
Date: Tue, 31 Aug 2010 19:51:16 +0200

Hi,

> only for them). Provider is monitoring operational status of 6to4 relay, 

And the response traffic takes this relay, because...?

> provider would be doing the same....

"If".  But this is not so, and therefore, 6to4 with anycast relay is
just not something that makes sense for global traffic.

> relay anymore since I am using native IPv6 both at home and at work.

Our (well-maintained!!) 6to4 relay works very well for traffic between
our users and our IPv6-enabled machines - but as soon as the users have 
native IPv6, no more need for the relay...

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

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

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 31 Aug 2010 12:19:47 -0700

This whole thread reminds me of the Adventure endgame where
it says "CAVE DOOR CLOSING" - the end of all things and time
to take inventory. We have gathered 6to4, teredo, 6rd, and
maybe even a little isatap and tunnel broker in our collective
treasure bag. Now mix them all up, shake well, and what pops
out is the Internet Routing Overlay Network (IRON).

Fred

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Gert Doering
> Sent: Tuesday, August 31, 2010 10:51 AM
> To: Mohacsi Janos
> Cc: Gunter Van de Velde (gvandeve); Rémi Després; Randy Bush; Cameron Byrne; IPv6 v6ops

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 01 Sep 2010 10:37:31 +1200

On 2010-09-01 05:34, Mohacsi Janos wrote:
>> Can be mananaged... but... if you use 6to4, then do you know the
>> person running the relays? Do you even know who is running the relays?
>> And why should the people running the relays care about you if you are
>> not there direct customer?
> 

Exactly. RFC 3056 describes how to manage 6to4. Unfortunately, RFC 3068
describes how to not manage it. Gunter's comment can apply to RFC 3068
but not to 6to4 as originally defined.

    Brian

> 
> For example I used to know who is running the 6to4 relay used by
> me...(me and network operation team).  For 1.5 years I don't care much
> about 6to4 relay anymore since I am using native IPv6 both at home and
> at work.
> 
> Best Regards,
>     Janos Mohacsi
> 
> 
>>
>> G/
>>
>>> Next to that... teredo and 6to4 are non-managed services, while 6rd
>>> is a managed service... big difference for the user experience.
>>>
>>> Descending to 100m, one can see that, unlike Teredo and 6to4, 6rd
>>> provides native IPv6 prefixes to customer sites, unlike Teredo and 6to4:
>>> - Hosts behind a 6rd CPE are on a dual-stack LAN, and can't determine
>>> whether the ISP network is dual stack throughout or 6rd.
>>> - From 6rd sites, connectivity with other IPv6 native addresses is
>>> guaranteed, which is the case with neither Teredo nor 6to4.
>>>
>>> PS: Note that I have absolutely no financial interest in any of its
>>> actual applications, just being proud of having originated a useful
>>> mechanism.
>>>
>>>
>>>
>>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 01 Sep 2010 11:01:49 +1200

> And the response traffic takes this relay, because...?

Actually, it doesn't. It takes whatever relay 2002::/16 happens to be
routed to at the remote host's location. It's when there is no
such route to a "willing" relay that 6to4 fails. That is the analysis
that's missing in draft-vandevelde-v6ops-harmful-tunnels.

> just not something that makes sense for global traffic.

Well, the problem is usually not the anycast relay, but the return path.
However, I agree; the problem cases seem to be caused by RFC 3068.

     Brian