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

Seiichi Kawamura <kawamucho@mesh.ad.jp> Tue, 17 August 2010 04:49 UTC

Return-Path: <kawamucho@mesh.ad.jp>
X-Original-To: v4tov6transition@core3.amsl.com
Delivered-To: v4tov6transition@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EC5E3A6809 for <v4tov6transition@core3.amsl.com>; Mon, 16 Aug 2010 21:49:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.063
X-Spam-Level:
X-Spam-Status: No, score=0.063 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265]
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 n-iKKPb5CFn3 for <v4tov6transition@core3.amsl.com>; Mon, 16 Aug 2010 21:49:25 -0700 (PDT)
Received: from tyo201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.193]) by core3.amsl.com (Postfix) with ESMTP id A070E3A67A4 for <v4tov6transition@ietf.org>; Mon, 16 Aug 2010 21:49:22 -0700 (PDT)
Received: from mailgate3.nec.co.jp ([10.7.69.193]) by tyo201.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id o7H4nutf009756; Tue, 17 Aug 2010 13:49:56 +0900 (JST)
Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id o7H4nua22562; Tue, 17 Aug 2010 13:49:56 +0900 (JST)
Received: from bgas200085.sys.biglobe.nec.co.jp (bgas200085.sys.biglobe.nec.co.jp [10.82.141.45]) by mailsv.nec.co.jp (8.13.8/8.13.4) with ESMTP id o7H4ntRZ007563; Tue, 17 Aug 2010 13:49:56 +0900 (JST)
Received: from mail.sys.biglobe.nec.co.jp (localhost [127.0.0.1]) by bgas200085.sys.biglobe.nec.co.jp (BINGO/BINGO/06101717) with ESMTP id o7H4ntb5029635; Tue, 17 Aug 2010 13:49:55 +0900
Received: from mail.sys.biglobe.nec.co.jp (bgsx5626.sys.biglobe.nec.co.jp [10.18.151.10]) (envelope-from kawamucho@mesh.ad.jp) by mail.sys.biglobe.nec.co.jp (BINGO/BINGO/10031711) with ESMTP id o7H4ntRY027777 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Aug 2010 13:49:55 +0900
Received: from [127.0.0.1] (edonet065.sys.biglobe.nec.co.jp [10.19.137.65]) (authenticated bits=0) (envelope-from kawamucho@mesh.ad.jp) by mail.sys.biglobe.nec.co.jp (BINGO/BINGO/10031711) with ESMTP id o7H4nt1p000522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Aug 2010 13:49:55 +0900
Message-ID: <4C6A14F2.9090107@mesh.ad.jp>
Date: Tue, 17 Aug 2010 13:49:54 +0900
From: Seiichi Kawamura <kawamucho@mesh.ad.jp>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: v4transition@googlegroups.com
References: <018544C5-8D1E-412A-B6E4-F12623E66366@cisco.com> <3CEE3B27-7926-48A6-A4A4-BEC1B5C9AD5E@cisco.com>
In-Reply-To: <3CEE3B27-7926-48A6-A4A4-BEC1B5C9AD5E@cisco.com>
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: v4tov6transition@ietf.org
Subject: Re: [v4tov6transition] Fwd: draft-arkko-ipv6-transition-guidelines WGLC
X-BeenThere: v4tov6transition@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <v4tov6transition.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/v4tov6transition>, <mailto:v4tov6transition-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v4tov6transition>
List-Post: <mailto:v4tov6transition@ietf.org>
List-Help: <mailto:v4tov6transition-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v4tov6transition>, <mailto:v4tov6transition-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Aug 2010 04:49:27 -0000

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