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

[Fred Baker <[e-mail]>]

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.