RE: [v4tov6transition] draft-arkko-ipv6-transition-guidelines WGLC

"Hemant Singh (shemant)" <shemant@cisco.com> Wed, 18 August 2010 19:47 UTC

Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A5E13A69A5 for <ietfarch-v6ops-archive@core3.amsl.com>; Wed, 18 Aug 2010 12:47:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.075
X-Spam-Level:
X-Spam-Status: No, score=-9.075 tagged_above=-999 required=5 tests=[AWL=-1.180, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UPKbRDjO8aKa for <ietfarch-v6ops-archive@core3.amsl.com>; Wed, 18 Aug 2010 12:47:51 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6BD153A67AC for <v6ops-archive@lists.ietf.org>; Wed, 18 Aug 2010 12:47:50 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from <owner-v6ops@ops.ietf.org>) id 1OloaB-0008lr-Nd for v6ops-data0@psg.com; Wed, 18 Aug 2010 19:45:55 +0000
Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from <shemant@cisco.com>) id 1Oloa3-0008kv-CF for v6ops@ops.ietf.org; Wed, 18 Aug 2010 19:45:48 +0000
Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAM/Va0ytJV2a/2dsb2JhbACgU3GlIJt0hTcEhDGIKA
X-IronPort-AV: E=Sophos;i="4.56,229,1280707200"; d="scan'208";a="149208937"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rtp-iport-1.cisco.com with ESMTP; 18 Aug 2010 19:45:33 +0000
Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id o7IJjXCs022338; Wed, 18 Aug 2010 19:45:33 GMT
Received: from xmb-rcd-114.cisco.com ([72.163.62.156]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 18 Aug 2010 14:45:32 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [v4tov6transition] draft-arkko-ipv6-transition-guidelines WGLC
Date: Wed, 18 Aug 2010 14:45:31 -0500
Message-ID: <AF742F21C1FCEE4DAB7F4842ABDC511C0268D1CA@XMB-RCD-114.cisco.com>
In-Reply-To: <55CF41D1D1344F3684F21C134E9A4B1D@china.huawei.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [v4tov6transition] draft-arkko-ipv6-transition-guidelines WGLC
Thread-Index: Acs+w9fwWzLeP2njQ/+1OtC62jzYjAAR0ATw
References: <018544C5-8D1E-412A-B6E4-F12623E66366@cisco.com> <3CEE3B27-7926-48A6-A4A4-BEC1B5C9AD5E@cisco.com> <4C6A14F2.9090107@mesh.ad.jp> <364D16EC-7E20-4B4B-A717-ADBED7552DA4@cisco.com> <BEF4F432142B4F4782C9D597E241E708@china.huawei.com> <AB6EEF7D-04D4-49B9-A8DB-A0878922A781@cisco.com> <A55047EB88134CB1B0541F5BE29F3243@china.huawei.com> <282BBE8A501E1F4DA9C775F964BB21FE3EADE5554B@GRFMBX704BA020.griffon.local> <55CF41D1D1344F3684F21C134E9A4B1D@china.huawei.com>
From: "Hemant Singh (shemant)" <shemant@cisco.com>
To: Tina TSOU <tena@huawei.com>, yiu_lee@cable.comcast.com, "Fred Baker (fred)" <fred@cisco.com>, Maglione Roberta <roberta.maglione@telecomitalia.it>
Cc: v6ops@ops.ietf.org, jari.arkko@piuha.net, v4tov6transition@ietf.org
X-OriginalArrivalTime: 18 Aug 2010 19:45:32.0599 (UTC) FILETIME=[EB5BFC70:01CB3F0D]
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

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.

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

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. 

  How do you use link-local?

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

  Is there RFC1918 space in IPv6?

   The ULA.

  Is there such a thing as secondary address with IPv6?

   No.

Hemant

-----Original Message-----
From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Tina TSOU
Sent: Wednesday, August 18, 2010 6:50 AM
To: yiu_lee@cable.comcast.com; Fred Baker (fred); Maglione Roberta
Cc: v6ops@ops.ietf.org; jari.arkko@piuha.net; v4tov6transition@ietf.org
Subject: Re: [v4tov6transition] draft-arkko-ipv6-transition-guidelines WGLC

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?

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


2. From: "Victor Kuarsingh" <Victor.Kuarsingh@rci.rogers.com>

- 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" <yiu_lee@cable.comcast.com>

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

----- Original Message ----- 
From: "Maglione Roberta" <roberta.maglione@telecomitalia.it>
To: "'Tina TSOU'" <tena@huawei.com>; "Fred Baker" <fred@cisco.com>; 
<yiu_lee@cable.comcast.com>
Cc: <v4tov6transition@ietf.org>; <jari.arkko@piuha.net>; 
<v6ops@ops.ietf.org>
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?
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: v4tov6transition-bounces@ietf.org 
[mailto:v4tov6transition-bounces@ietf.org] On Behalf Of Tina TSOU
Sent: mercoledì 18 agosto 2010 3.37
To: Fred Baker; v4transition@googlegroups.com
Cc: v4tov6transition@ietf.org
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" <fred@cisco.com>
To: <v4transition@googlegroups.com>
Cc: <v4tov6transition@ietf.org>
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" <fred@cisco.com>
>> To: <v4transition@googlegroups.com>
>> 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
>>>> v6ops@ops.ietf.org if we have not, read the document, and comment on it
>>>> on v6ops@ops.ietf.org 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 v6ops@ops.ietf.org prior to that.
>>>>
>>>> Begin forwarded message:
>>>>
>>>>> From: Fred Baker <fred@cisco.com>
>>>>> Date: August 15, 2010 11:00:04 AM PDT
>>>>> To: v6ops@ops.ietf.org
>>>>> Cc: kurtis@kurtis.pp.se, rbonica@juniper.net
>>>>> 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
> v4tov6transition@ietf.org
> https://www.ietf.org/mailman/listinfo/v4tov6transition
>


_______________________________________________
v4tov6transition mailing list
v4tov6transition@ietf.org
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.