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

Seiichi Kawamura <kawamucho@mesh.ad.jp> Thu, 19 August 2010 01:04 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 074603A6817 for <v4tov6transition@core3.amsl.com>; Wed, 18 Aug 2010 18:04:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.056
X-Spam-Level:
X-Spam-Status: No, score=0.056 tagged_above=-999 required=5 tests=[AWL=0.146, 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 eZ42B89vqrel for <v4tov6transition@core3.amsl.com>; Wed, 18 Aug 2010 18:04:14 -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 6A5833A68BD for <v4tov6transition@ietf.org>; Wed, 18 Aug 2010 18:04:14 -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 o7J14kkQ018683; Thu, 19 Aug 2010 10:04:46 +0900 (JST)
Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id o7J14kr07616; Thu, 19 Aug 2010 10:04:46 +0900 (JST)
Received: from bgas200085.sys.biglobe.nec.co.jp (bgas200085.sys.biglobe.nec.co.jp [10.82.141.45]) by mailsv4.nec.co.jp (8.13.8/8.13.4) with ESMTP id o7J14jTA017212; Thu, 19 Aug 2010 10:04:45 +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 o7J14jtb015356; Thu, 19 Aug 2010 10:04:45 +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 o7J14jgc025524 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Aug 2010 10:04:45 +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 o7J14jSk032174 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Aug 2010 10:04:45 +0900
Message-ID: <4C6C832C.2010103@mesh.ad.jp>
Date: Thu, 19 Aug 2010 10:04:44 +0900
From: Seiichi Kawamura <kawamucho@mesh.ad.jp>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Fred Baker <fred@cisco.com>
References: <018544C5-8D1E-412A-B6E4-F12623E66366@cisco.com> <3CEE3B27-7926-48A6-A4A4-BEC1B5C9AD5E@cisco.com> <4C6A14F2.9090107@mesh.ad.jp> <EBD74DD5-010D-46EA-A1D1-B67D3042E84E@cisco.com>
In-Reply-To: <EBD74DD5-010D-46EA-A1D1-B67D3042E84E@cisco.com>
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: Randy Bush <randy@psg.com>, Philip Smith <pfs@cisco.com>, "v6ops@ops.ietf.org Operations" <v6ops@ops.ietf.org>, v4tov6transition@ietf.org
Subject: Re: [v4tov6transition] 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: Thu, 19 Aug 2010 01:04:17 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

Fred Baker wrote:
> 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...

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.

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

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)

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

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

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

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

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

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.

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

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?

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

Agree :-)

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

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.

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

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?

> 
>> Why is VRRPv3's global VIP optional and not implemented by some?
> 
> 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

> 
>> 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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iEYEARECAAYFAkxsgysACgkQcrhTYfxyMkJmbwCgj1ie+RqU0jAW+TOpu/oo9ExB
0nMAn3yAJy4QhxTKsErZ7xVP7VXYqlJW
=Zj0P
-----END PGP SIGNATURE-----