This discussion is locked

Ask the Expert: IPv6 Routing Protocols

Unanswered Question
Oct 18th, 2013

IPv6 Routing ProtocolsWith Cisco Designated VIP Peter Palúch

Welcome to the Cisco Support Community Ask the Expert conversation. This is an opportunity to learn and ask questions about about how to plan, design, implement, and troubleshoot IPv6 routing protocols in your network infrastructure, including in-depth information about their operation with Cisco Designated VIP Peter Palúch.


With the increasing rate of IPv6 deployment, issues with dual operation of IPv4 and IPv6 are also compounded with the need of running appropriate routing protocols. This event provides an opportunity to ask about Open Shortest Path First version 3 (OSPFv3), Intermediate System-to-Intermediate System (IS-IS) Protocol, Enhanced Interior Gateway Routing Protocol (EIGRP), Border Gateway Protocol (BGP), and Routing Information Protocol next generation (RIPng) and learn details about their operation, implementation, and optimization.  

Cisco designated VIP Peter Palúch is an assistant professor and a Cisco Networking Academy instructor at the University of Zilina, Slovakia. His fields of interest include routing, switching, and Multiprotocol Label Switching (MPLS) technologies. He is a seasoned teacher who has cooperated in various educational activities in Slovakia and abroad, focusing particularly on networking and Linux-based network server systems. Peter holds a doctoral degree in the area of VoIP quality degradation factors; he also holds CCIP certification (retired by Cisco) and CCIE certification no. 23527 in routing and switching.


Remember to use the rating system to let Peter know if you've received an adequate response.


Because of the volume expected during this event, Peter might not be able to answer every question. Remember that you can continue the conversation in the Network Infrastructure community, subcommunity, WAN, Switching and Routing, shortly after the event. This event lasts through November 15, 2013. Visit this forum often to view responses to your questions and those of other Cisco Support Community members.

This event ends Friday, November 15 - Please be sure to post your questions now!      

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Average Rating: 5 (15 ratings)
Jessica Deaken Mon, 11/04/2013 - 11:49

Hello Peter,

I am having difficulties understanding the use of link-local addresses and their purpose in IGP protocols. Why are they used as next hop addresses? Looking into my IPv6 routing table, verifying if a particular route goes through the proper next hop is a mess: reading the link-local addresses and finding out which address corresponds to which router is even worse than learning MAC addresses.  Could you please help?

Thank you,

Jessica

JohnTylerPearce Mon, 11/04/2013 - 12:34

I have a question pertaining to the subnet prefix in an IPv6 network From my understanding IANA allocated the first 48-bits of an IPv6 address, and leaves the site an additional 16-bits for subnet usage. My question is, as far as the IPv6 global routing table goes, let's say I have an address 12BE:BEEF:BEEF::/48 assigned to me. Which that prefix be associated with the Internet Routes or if I created 12BE:BEEF:BEEF:BEE2/64 be associated as well?

I guess this is more of a IPv6 Hierarchical question.

Peter Paluch Mon, 11/04/2013 - 14:37

Hi John,

From my understanding IANA allocated the first 48-bits of an IPv6  address, and leaves the site an additional 16-bits for subnet usage.

Well, if you are an end customer then IANA's allocation is at least two logical levels above you - the regional internet registries, and then your provider. IANA allocates much shorter prefixes, see here:

http://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml

An end customer was traditionally allocated a /48 prefix from its ISP. This was to facilitate a more than reasonable number of subnets for the customer, plus to allow automatic mechanisms such as modified EUI-64 to have their 64-bit sandbox to play with, to allow relatively easy renumbering if the agreed-upon /48 prefix changes. However, many feel that allocating a /48 prefix to a small end customer is not justified. The RFC 6177 questions this policy and suggests that longer prefixes are allocated to end customers.

My question is, as far as the IPv6 global routing table goes, let's say I  have an address 12BE:BEEF:BEEF::/48 assigned to me. Which that prefix  be associated with the Internet Routes or if I created  12BE:BEEF:BEEF:BEE2/64 be associated as well?

This is really a matter of prefix summarization. Your routing protocol could advertise the subnetted prefixes to your ISP, or it could have already summarized the prefixes to 12BE:BEEF:BEEF::/48. And because your ISP obtained a certain IPv6 prefix itself from its regional internet registry, it can also advertise just this summary prefix to neighboring ASes.

So whether your /64 prefix appears in internet routing tables depends on the configuration of your ISP, its own ISPs (the tiers), and of course, whether you are using PI (provider-independent) address space. I've just checked the Route Views router (telnet into route-views.routeviews.org using the rviews as the login, no password), and this is what it tells me:

route-views>show ipv6 route  summary

IPv6 routing table name is Default(0) global scope - 15753 entries

IPv6 routing table default maximum-paths is 16

Route Source    Networks    Overhead    Memory (bytes)

connected       1           96          128        

local           2           192         256        

bgp 6447        15740       1511040     2014720    

  Internal: 0  External: 15740  Local: 0

static          10          960         1280       

  Static: 10  Per-user static: 0

Total           15753       1512288     2016384    

  Number of prefixes:

    /0: 1, /3: 1, /8: 1, /12: 4, /16: 1, /19: 2, /20: 7, /21: 3

    /22: 5, /23: 5, /24: 11, /25: 4, /26: 11, /27: 17, /28: 51, /29: 288

    /30: 51, /31: 50, /32: 5379, /33: 139, /34: 102, /35: 150, /36: 617, /37: 31

    /38: 196, /39: 59, /40: 728, /41: 37, /42: 102, /43: 10, /44: 604, /45: 71

    /46: 101, /47: 110, /48: 6236, /49: 17, /50: 2, /51: 2, /52: 8, /53: 2

    /54: 1, /56: 76, /58: 1, /60: 5, /61: 4, /62: 4, /63: 4, /64: 307

    /112: 1, /120: 1, /123: 2, /124: 2, /125: 3, /126: 72, /127: 14, /128: 40

route-views>

As you can see, there are some prefixes equal or longer to /64. They may be internal to the AS in which this router runs (hence not summarized yet), or they may come from PI space of different customers.

Feel welcome to ask further!

Best regards,

Peter

Peter Paluch Mon, 11/04/2013 - 14:11

Hi Jessica,

The link-local addresses in IPv6 are somewhat controversial but once you get used to them (and tweak them a bit to suit your needs), you'll come to appreciate them.

In IPv6, all management traffic is IPv6-encapsulated. This goes for neighbor discovery, duplicate address detection, default gateway discovery, address autonegotiation, etc. As many of these operations serve to bootstrap your IPv6 settings, there is clearly a chicken-and-egg problem here: how can you use IPv6-encapsulated messages to obtain your IPv6 settings if you do not yet have an IPv6 address yourself?

Link-local addresses solve this problem, and in fact, they allow for a couple of other tricks not available in IPv4. As link-local addresses are always present and usable as next hop addresses in fully qualified route table entries (specified by both egress interface and the next hop address), they can be used to implement the IP Unnumbered-like functionality on transit links. It is not necessary to assign global addresses to transit links, because the link-local addresses will always be available. In addition, while IP Unnumbered is usable only on point-to-point links, unnumbered transit links using only link-local addresses can also be on multi-access technologies such as Ethernet.

In addition, in IPv6, your interface may have multiple IPv6 addresses configured. As these addresses may eventually come and go, there is no guarantee that any of these addresses is stable enough to be a next hop address for a route. Link-local addresses provide the necessary stability in this environment - regardless of how many IPv6 addresses your interfaces have, you can always rely on the presence of link-local addresses as usable next-hop addresses.

Also, the use of link-local addresses as next hop addresses allows you to gracefully renumber a transit network without actually causing any outage in teh connectivity. If you need to renumber a transit link, you simply go and do it: add a new IPv6 address, remove the old one. There should be absolutely no interruption in the network connectivity because the IGP routing protocols use link-local addresses as next hop, source, and possibly destination addresses in their packets, and even when you renumber a link, you do not touch the link-local addresses. Renumbering in IPv6 is much less disruptive than in IPv4.

The way link-local addresses are created using modified EUI-64 produces addresses not exactly pleasant to an untrained eye. Knowing what link-local address corresponds to which router on a segment is really at roughly the same level as learning MAC addresses of all routers on a segment. This is why I strongly recommend redefining even the link-local addresses using the ipv6 address FE80:X:...:X link-local interface level command to some sensible values that are meaningful to you. This way, you can make the link-local addresses more comprehensible while retaining the advantages of link-local addressing as described earlier.

Additional questions on this topic are most welcome!

Best regards,

Peter

JohnTylerPearce Mon, 11/04/2013 - 15:18

You know Peter, if you had a dollar for every question you have answered for me, you would be a rich man.

Anyway, so let's say my ISP has assigned me 1234:BEEF:BEEF:BEEF::/64.

Now I"m using EUI-64, and my MAC address is abce.bf34.232d

So my full host address is

1234:BEEF:BEEF:BEEF:A9CE:BFFF:FE34:232D (I believe I did the conversion correctly)

So, if a web server is sending my HTTP data, it's going to go through the IPv6 Hierarchy, go to my RIR, my local ISP, and then if will route it to my CE router, and then once it hits the CE router, it will send a Neighbor Discovery to get my exact location

Now, I know it's not necessary as neat and clean like this, but just wanted to get the basic idea down.

Peter Paluch Tue, 11/05/2013 - 00:36

Hi John,

You know Peter, if you had a dollar for every question you have answered for me, you would be a rich man.

Your satisfaction is rewarding enough. Thank you!

So my full host address is

1234:BEEF:BEEF:BEEF:A9CE:BFFF:FE34:232D (I believe I did the conversion correctly)

So,  if a web server is sending my HTTP data, it's going to go through the  IPv6 Hierarchy, go to my RIR, my local ISP, and then if will route it to  my CE router, and then once it hits the CE router, it will send a  Neighbor Discovery to get my exact location

Perhaps a nitpicking remark, but the RIR is just a regulatory body - it is not a internet service provider. While a RIR is in charge of assigning IPv4/IPv6 addresses to ISPs, packets are not routed through a RIR.

The routing and prefix advertisement in IPv6 is identical to IPv4. You get a prefix, you may optionally subnet it, and you may either advertise the subnetted prefixes or just the original unsubnetted prefix. Packet destined for a prefix undergo precisely the same routing process as in IPv4 (you can either think of it as ANDing the destination addresses with netmasks which now have 128 bits and matching the result with the network address in the corresponding routing table entry, or doing a longest prefix match based on so-called prefix trees if you are familiar with CEF FIB organization - in any case, this all is very same as in IPv4 routing), and once the packet arrives at a router whose matching IPv6 network is directly connected, the router will use the Neighbor Discovery process to find the MAC address of the destination host, and will forward the packet to it.

The bottom line is: subnetting, advertising prefixes, using the routing table to route packets, resolving next hop addresses - it all works in the same manner as in IPv4. Slight changes are natural (ICMPv6 instead of ARP, no broadcasts, use of specific multicasts, etc.) but the underlying principle is still the same.

Please feel welcome to ask further!

Best regards,

Peter

johnlloyd_13 Wed, 11/06/2013 - 18:47

Hi Peter,

Nice forum going here. My question isn't that really technically deep but here it goes. I'm curious and always intrigued with what happened to the "reserved" Class D and E of the RFC 1918 private IPv4 address space.

Will this be used for commercial/ISP purpose or will the Internet/IEEE folks will keep this as reserved and enforce to use IPv6?

Sent from Cisco Technical Support iPhone App

Peter Paluch Thu, 11/07/2013 - 00:26

Hi John,

Thank you for joining and for your question!

what happened to the "reserved" Class D and E of the RFC 1918 private IPv4 address space.

You probably mean just the classes D and E. I have double-checked the RFC 1918 but it only specifies reserved addresses from the former class A (10.0.0.0/8), B (172.16.0.0/12), and C (192.168.0.0/16). It does not tap into multicast or experimental addresses.

Will this be used for commercial/ISP purpose or will the Internet/IEEE folks will keep this as reserved and enforce to use IPv6?

My personal belief is that the reserved addresses will remain reserved as they are today.

The entire Class D is reserved for multicast applications and different applications/groups are spread all over its current scope so there is nothing, really, that could be "cut off" the D class and reassigned to usable unicast space.

As for the Class E, it could arguably be reclaimed as usable unicast IPv4 space. However, IANA still keeps this scope listed as an experimental reserved scope and there seem to be no plans to change this. Even if IANA reclassified the Class E scope to usable address space, most operating systems currently reject Class E addresses. It is practically unthinkable of starting using the Class E scope with the hope that old and new operating systems will be happy with it. Even if vendors updated their current OSes in this sense - which could take years - the older and unsupported operating systems would be simply unable to communicate with the Class E space. Simply put, it is too late to allow the use of Class E scope.

Please feel welcome to discuss this further!

Best regards,

Peter

johnlloyd_13 Thu, 11/07/2013 - 05:17

Peter,

Thanks for your feedback and technical insights! It's always been a pleasure reading your answers and wonderful explanation.

I hope for more "Ask the Expert" forum from you.

Sent from Cisco Technical Support iPhone App

Peter Paluch Thu, 11/07/2013 - 06:02

John,

It is always a pleasure. Please keep the questions coming - they (and only they) keep the Ask the Expert sessions alive!

Best regards,

Peter

tenaro.gusatu.novici Fri, 11/15/2013 - 09:29

Hi again,

let me first say a big thanks for a really great discussion! I especially like your personal comments, it gives all of this additional dimension that we can't find in ordinary documents.

Quick follow up to Jessica's post: Are link local addresses mandatory part of IPv6? I'm asking because I think (meaning I'm not sure) that some devices that I used in the past displayed only one IPv6 address (one that I configured manually, something like 2001::4). I guess there is another way to ask the same question: can we disable use of local link addresses completely?

And one more: are you telling us that local link addresses are equally important as manually configured addresses (or even more important)? Does it mean that OSPFv3 will take into account local link addresses too when creating SPF tree? What is then used as primary source address when generating IPv6 packet? I never thought about this before; here is another benefit why this discussions are so useful

Cheers,

Tenaro

Peter Paluch Fri, 11/15/2013 - 22:18

Hi Tenaro,

I would like to thank you - it's the questions and members of this thread who make it such a great place to be.

Quick follow up to Jessica's post: Are link local addresses mandatory part of IPv6?

Yes, they are. Every IPv6-enabled interface must have a link-local address, and may have additional addresses. I would personally consider any deviation from this rule as breaking the IPv6 standard.

I'm asking because I think (meaning I'm not sure) that some devices that  I used in the past displayed only one IPv6 address (one that I  configured manually, something like 2001::4).

The link-local addresses are generated automatically for an interface once you enable IPv6 on it, so most of the time, you do not bother with the link-local addresses at all. It is probable that the devices simply did not display the link-local address but I am sure they have been using them.

I guess there is another way to ask the same question: can we disable use of local link addresses completely?

To my best knowledge, this is not possible. Link-local addresses must be present.

And one more: are you telling us that local link addresses are equally  important as manually configured addresses (or even more important)?

Yes, absolutely. Apart from other uses, link-local addresses are going to be used as next hop addresses for all IGP-learned routes. Note that even your Windows or Linux station running IPv6 has a link-local address of your router configured as its default gateway if running SLAAC or DHCPv6.

Does it mean that OSPFv3 will take into account local link addresses too when creating SPF tree?

Precisely! That is why they are advertised in LSA-8 with a link-local flooding scope. In OSPFv3, the LSA-8 carry link-local addresses (and information about the neighbor's configured prefixes on its interface towards us), and LSA-9 carry the global prefixes on each intra-area link and/or interface.

What is then used as primary source address when generating IPv6 packet?

IGP protocols always use the link-local address to source their packets from. In other words, you can start an IPv6 IGP routing protocol over an interface as soon as it has been IPv6-enabled and has its link-local address assigned. Further operations on the interface with adding/removing global IPv6 addresses have no influence on the IGP communication over that interface, because IGP protocols send their packets using the link-local address of the egress interface. (Exceptions like OSPFv3 virtual link do exist but let's not complicate things here.)

The source address selection in IPv6 is a complex topic; see RFC 6724 for details. This RFC does not cover IGP protocols, though.

So - yeah, link-local addresses are certainly something keeping an eye on

Best regards,

Peter

tenaro.gusatu.novici Mon, 11/04/2013 - 18:03

Hi Peter,

long time ago I attended some Cisco presentations and would like to clear few things before I start with "rea" questions   Could you please reply on following questions/comments:

- "Firewalls will go away and we'll  dance on their graves" - it was nice visual description of what will  happen with FWs once IPv6 replaces IPv4; I'm sure sales guys will try to  convince us today in the opposite but would like to hear your/technical  comment.

- Are you aware if Cisco supports IPv6 in current computing  products (talking about UCS devices here) or collaboration portfolio  (like CUCM, voicemail, IP phones or Tandberg/Telepresence devices)?

- Is there any need for Mobile IP feature in IPv6 world?

- Do we need DHCP server in LAN as all these addresses are automatically created/generated by endpoints and the gateway itself?

Thanks,

Tenaro

Peter Paluch Tue, 11/05/2013 - 01:16

Hi Tenaro,

Thank you for joining and your questions!

- "Firewalls will go away and we'll  dance on their graves" - it was  nice visual description of what will  happen with FWs once IPv6 replaces  IPv4; I'm sure sales guys will try to  convince us today in the  opposite but would like to hear your/technical  comment.

This statement is most surprising to me, and I do not agree with it. Perhaps the presentation speaker had specifically the Network Address Translation (NAT) in mind that is often performed by firewalls. IPv6 was designed with the notion of having so many addresses that NAT is no longer necessary - perhaps that was the motivation of the speaker to say that NAT boxes won't be necessary anymore.

The truth is - NAT has been used for more purposes than just address conservation. It allowed for anonymization of internal network hosts, and also, it provided a certain degree of security - you can not initate a session to an internal host if there is no appropriate entry created in the NAT table that would do the proper address rewriting. Without NAT, every IPv6 address is exposed and directly visible, so if it is a global address, it can always be used to identify you and to contact you directly. While IPv4 hosts behind NAT were relatively safe as the outside world had very limited options of attacking them (or even knowing who they are), these very same hosts on IPv6 without NAT are directly visible, traceable, and without a proper firewall - either on the hosts alone or in the network - they are exposed to outside world unprotected. You may find this amusing, but the Linux kernel already has two different modes of NAT for IPv6 - the so-called masquerade (basically a source NAT) and network prefix translation per RFC 6296. So much for that NAT-free IPv6

Another perception that IPv6 would be significantly more secure was created the original intention of making IPsec a requirement for IPv6 hosts. That ultimately did not work, and this strict requirement was even dropped. IPsec is hard to set up on a larger scale, and no one can force you to use it, anyway.

Dancing on firewalls' graves? I am afraid if we did that, firewalls would soon be dancing on our graves

- Are you aware if Cisco supports IPv6 in current computing  products  (talking about UCS devices here) or collaboration portfolio  (like CUCM,  voicemail, IP phones or Tandberg/Telepresence devices)?

Let me find this out for you. I am fairly sure that the majority of most recent Cisco products has a dual support for both IPv4 and IPv6, as Cisco has been an avid proponent of IPv6 for a very long time. Then again, business plans often override sensible ideas, so let's not jump into conclusions. I will find this out with my Cisco contacts and update you on this.

- Is there any need for Mobile IP feature in IPv6 world?

Oh, the need is definitely there, just the implementation is very poor. Just think of having a simple smartphone or a tablet with either a download ongoing, or a call underway. These devices are built to be mobile, so you want your open network sessions to remain working while you move with the device and roam from one network to another. Without IPv6 Mobile or an equivalent mechanism, the sessions will inevitably close when you change IPv6 networks. And with the Internet of Things, issues of mobility with continuous reachability become even more serious.

The need for a working mobility solution is also underlined by the fact that the Locator/Identifier Separation Protocol (LISP) has one of its major use cases in facilitating mobility. In this protocol, your identity remains always constant, just your location changes. Some very nice applications are built on this.

So the bottom line is - the need is there, just somehow the operating system vendors do not reflect on it. Perhaps it is a vicious circle - it is not implemented, so people are not using it, not even knowing it's possible, so they don't push on the vendors of their OSes to implement it.

- Do we need DHCP server in LAN as all these addresses are automatically created/generated by endpoints and the gateway itself?

A very good observation. The Stateless Address Auto Configuration (SLAAC), which is the fancy name for a station learning the network prefix from the Router Advertisement (RA) messages, allows for relatively limited IPv6 configuration. What you really get using SLAAC is your IPv6 address and the address of the default gateway. That's it. You don't even learn about a DNS server address (although the RFC 6106 tries to define an information element to RA messages to carry the DNS address and search list, it is not widely implemented yet). Delivering settings such as IP address of a TFTP server for IP phones, address of a WLC controller, web proxy settings, time server, defining various policies for IPv6 address assignment to different stations, you name it - you just can't do it using SLAAC. You need DHCPv6 for this.

In addition, there is no logging available for station's addresses derived via SLAAC. The stations may use any arbitrary identifier in the address's host part which is at the core of IPv6 Privacy Extensions RFC 4941. You as an administrator have no control over it, and also you have no log entries to know which station in your network used which SLAAC-derived address, and in what time. Should a security incident occur, sourced from one of SLAAC-derived randomized addresses somewhere in your network, it is practically impossible to track the attack back to its source.

DHCPv6 has a provision for assignig so-called temporary addresses which are practically equivalent to randomized addresses, and the advantage is that your DHCP server then becomes the source of information which station used which temporary address and in what time. That can remedy the issues caused by the total anonymity of stations with random SLAAC addresses.

In very simple scenarios like home networks, SLAAC is perfectly fine. In more controlled environments, the DHCP is a must.

would like to clear few things before I start with "rea" questions 

Looking forward to reading them

Best regards,

Peter

Peter Paluch Tue, 11/05/2013 - 10:08

Hello Tenaro,

- Are you aware if Cisco supports IPv6 in current computing  products  (talking about UCS devices here) or collaboration portfolio  (like CUCM,  voicemail, IP phones or Tandberg/Telepresence devices)?

I have asked Edison Ortiz and this is what he wrote me:

So it seems that the IPv6 support is coming along nicely in the products you have asked about.

Best regards,

Peter

Jessica Deaken Wed, 11/06/2013 - 16:01

Hi Peter,

Thank you for the detailed answer! I have another question.  The IS-IS is said to be a multiprotocol routing protocol. What does it really mean? Can I run it in a network that uses both IPv4 and IPv6? How is it different from running, say, EIGRP both for IPv4 and IPv6?

Thank you,

Jessica

Peter Paluch Thu, 11/07/2013 - 20:37

Hi Jessica,

A routing protocol has a "multiprotocol" quality if it is able, in one instance, carry information about multiple routed protocols (also often called address families). You start only a single instance of such routing protocol, but its messages are capable of carrying information about multiple address families at once. Depending on how the routing protocol internally works, this may have multiple advantages:

  • A single run of the routing protocol's best path algorithm computes shortest paths to networks in all address families because the underlying network topology is the same for all routed protocols used over it, saving CPU cycles
  • A single configuration of the routing protocol, including interface metrics, authentication, etc. applies to all address families at once, making the routing protocol's behavior consistent in multiple address families
  • The consumption of router's resources is potentially smaller because you do not need to keep separate routing protocol's working data such as neighbor tables, adjacencies, link-state databases or topology tables, internal RIBs etc. for each address family, clearly duplicating lots of identical information for each address family.
  • Adding a new routed protocol and routing for it into a network is easier from the deployment perspective, because instead of starting a separate routing protocol, you just activate a new address family in your existing multiprotocol routing protocol

Traditionally, BGPv4 and IS-IS have been multiprotocol-capable for a very long time; their very nature allowes for this approach. Recently, OSPFv3 and EIGRP have also become multiprotocol-capable. IS-IS has a specific position among these protocols, though, because of the way it carries the addressing information in its messages, and the way its messages are encapsulated: they are immediately placed in Layer2 frames without any intermediary Layer3 protocol. This makes IS-IS very strongly detached from any particular Layer3 protocol, and makes the carried Layer3 addressing information to become merely an attribute of a router to which a particular Layer3 network is attached. Extending the IS-IS protocol for a new address family therefore means simply adding information elements for the new address formats, and that's it. It's not surprising at all that it was exactly the IS-IS that was the natural choice for TRILL and FabricPath technologies, as it was very easily extended to provide shortest path computation between RBridges (or FP switches).

Consider a network with three routers connected in a row, R1, R2, and R3. Each of these routers has a loopack; R1-R2 are using FastEthernet to each other, R2-R3 are using Serial interface to each other. All loopbacks and router interconnections are addressed both with IPv4 and IPv6, and IS-IS is run in this network for both IPv4 and IPv6. This is how the relevant parts of R2's configuration look like:

hostname R2

!

ipv6 unicast-routing

ipv6 cef

!

interface Loopback0

ip address 10.255.255.2 255.255.255.255

ip router isis

ipv6 address FDFF::2/128

ipv6 router isis

!

interface FastEthernet0/1

description => To R1 <=

ip address 10.1.12.2 255.255.255.0

ip router isis

duplex auto

speed auto

ipv6 address FE80:1::2 link-local

ipv6 address FD00:1:0:12::2/64

ipv6 router isis

!        

interface Serial1/0

description => To R3 <=

bandwidth 1000

ip address 10.0.23.2 255.255.255.0

ip router isis

ipv6 address FE80::2 link-local

ipv6 address FD00:0:0:23::2/64

ipv6 router isis

!

router isis

net 49.0001.0000.0000.0002.00

is-type level-1

metric-style wide

Note that only a single IS-IS process is started here; it is run both in IPv4 and IPv6 address family on interfaces thanks to ip router isis and ipv6 router isis commands. A single link-state database on R2 holds information about both IPv4 and IPv6 addresses:

R2# show isis database detail

IS-IS Level-1 Link State Database:

LSPID                 LSP Seq Num  LSP Checksum  LSP Holdtime      ATT/P/OL

R1.00-00              0x00000008   0x09F5        1107              0/0/0

  Area Address: 49.0001

  NLPID:        0xCC 0x8E

  Hostname: R1

  IP Address:   10.255.255.1

  Metric: 10         IP 10.1.12.0/24

  Metric: 10         IP 10.255.255.1/32

  IPv6 Address: FDFF::1

  Metric: 10         IPv6 FD00:1:0:12::/64

  Metric: 10         IPv6 FDFF::1/128

  Metric: 10         IS-Extended R2.01

R2.00-00            * 0x0000000A   0x1109        972               0/0/0

  Area Address: 49.0001

  NLPID:        0xCC 0x8E

  Hostname: R2

  IP Address:   10.255.255.2

  Metric: 10         IP 10.1.12.0/24

  Metric: 10         IP 10.0.23.0/24

  Metric: 10         IP 10.255.255.2/32

  IPv6 Address: FDFF::2

  Metric: 10         IPv6 FD00:1:0:12::/64

  Metric: 10         IPv6 FD00:0:0:23::/64

  Metric: 10         IPv6 FDFF::2/128

  Metric: 10         IS-Extended R2.01

  Metric: 10         IS-Extended R3.00

R2.01-00            * 0x00000004   0x5EE1        944               0/0/0

  Metric: 0          IS-Extended R2.00

  Metric: 0          IS-Extended R1.00

R3.00-00              0x00000009   0x3C9C        937               0/0/0

  Area Address: 49.0001

  NLPID:        0xCC 0x8E

  Hostname: R3

  IP Address:   10.255.255.3

  Metric: 10         IP 10.0.23.0/24

  Metric: 10         IP 10.255.255.3/32

  IPv6 Address: FDFF::3

  Metric: 10         IPv6 FD00:0:0:23::/64

  Metric: 10         IPv6 FDFF::3/128

  Metric: 10         IS-Extended R2.00

Notice how in this database, each router in succession advertises both its IPv4 and IPv6 directly attached networks. In IS-IS, this addressing information is very clearly separated from the topology information itself - the entries marked as IS-Extended designating a connection of a router to a neighboring object in the network, either another router or a transit network (in this case a transit network between R1 and R2). Addresses here become just an attribute of a router, and finding a potential path to a router means also finding a potential path to all addresses it advertises. Using this database, IS-IS computes a single shortest path tree for the network topology, and sorts out the located networks into appropriate routing tables according to their address family:

R2# show ip route isis

     10.0.0.0/8 is variably subnetted, 7 subnets, 2 masks

i L1    10.255.255.3/32 [115/20] via 10.0.23.3, Serial1/0

i L1    10.255.255.1/32 [115/20] via 10.1.12.1, FastEthernet0/1

R2# show ipv6 route isis

IPv6 Routing Table - 12 entries

Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP

       U - Per-user Static route, M - MIPv6

       I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary

       O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2

       ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2

       D - EIGRP, EX - EIGRP external

I1  FDFF::1/128 [115/20]

     via FE80:1::1, FastEthernet0/1

I1  FDFF::3/128 [115/20]

     via FE80::3, Serial1/0

As we will be running IPv4 and IPv6 simultaneously in our networks for a very long time to come, having multiprotocol routing protocols is a natural requirement. While the multiprotocol capability is slowly being adopted by all major routing protocols, IS-IS has this ability by design.

Anyone please feel welcome to ask further!

Best regards,

Peter

jan.hrnko Thu, 11/07/2013 - 10:39

Hi Peter,

First of all thank you for having this session, it is really nice to have you here answering our questions. I have quite a basic question regarding to OSPFv3 and its LSAs, but I would be most thankful for your insights.

My question is, why do we have LSA9 introduced in OSPFv3 instead of just having all the prefix information in LSA1 or LSA2, like we had in OSPFv2? In what particular is it better to have these information separated and does it affect the SPF algorithm? I mean, adding/removing a new network in a stable topology does not affect the tree that is already built and therefore you don't have to run SPF once more, is that it or am I wrong/missing something?

One more thing, from CCDA certification guide "The intra-area-prefix LSA is a new LSA type that is used to advertise IPv6 prefixes associated with a router, a stub network, or an associated transit network segment. This LSA

contains information that used to be part of the router LSAs and network LSAs."

Could I kindly ask you to explain, what could they mean by associated transit network segement?

Thank you very much!

Best regards,

Jan

Peter Paluch Fri, 11/08/2013 - 04:24

Hi Jan,

Thanks so much for joining!

My question is, why do we have LSA9 introduced in OSPFv3 instead of just  having all the prefix information in LSA1 or LSA2, like we had in  OSPFv2? In what particular is it better to have these information  separated and does it affect the SPF algorithm?

This will require some time to explain properly so please bear with me.

Let's focus our discussion on LSA1 and LSA2. These LSAs in OSPFv2 try to be very compact and express very much information in a small space. This is achieved by intertwinning the topology and addressing information. Check my previous response to Jessica about IS-IS being a multiprotocol routing protocol. On the same network, OSPFv2 (just for IPv4) would create the following LSAs:

R2# show ip ospf database router

            OSPF Router with ID (10.255.255.2) (Process ID 1)

        Router Link States (Area 0)

!!! LSA1 of R1 !!!

  LS age: 103

  Options: (No TOS-capability, DC)

  LS Type: Router Links

  Link State ID: 10.255.255.1

  Advertising Router: 10.255.255.1

  LS Seq Number: 80000007

  Checksum: 0xEBD4

  Length: 48

  Number of Links: 2

    Link connected to: a Transit Network

     (Link ID) Designated Router address: 10.1.12.2

     (Link Data) Router Interface address: 10.1.12.1

      Number of TOS metrics: 0

       TOS 0 Metrics: 10

    Link connected to: a Stub Network

     (Link ID) Network/subnet number: 10.255.255.1

     (Link Data) Network Mask: 255.255.255.255

      Number of TOS metrics: 0

       TOS 0 Metrics: 1

!!! LSA1 of R2 !!!

  LS age: 138

  Options: (No TOS-capability, DC)

  LS Type: Router Links

  Link State ID: 10.255.255.2

  Advertising Router: 10.255.255.2

  LS Seq Number: 80000008

  Checksum: 0x83FF

  Length: 72

  Number of Links: 4

    Link connected to: another Router (point-to-point)

     (Link ID) Neighboring Router ID: 10.255.255.3

     (Link Data) Router Interface address: 10.0.23.2

      Number of TOS metrics: 0

       TOS 0 Metrics: 100

    Link connected to: a Stub Network

     (Link ID) Network/subnet number: 10.0.23.0

     (Link Data) Network Mask: 255.255.255.0

      Number of TOS metrics: 0

       TOS 0 Metrics: 100

    Link connected to: a Transit Network

     (Link ID) Designated Router address: 10.1.12.2

     (Link Data) Router Interface address: 10.1.12.2

      Number of TOS metrics: 0

       TOS 0 Metrics: 10

    Link connected to: a Stub Network

     (Link ID) Network/subnet number: 10.255.255.2

     (Link Data) Network Mask: 255.255.255.255

      Number of TOS metrics: 0

       TOS 0 Metrics: 1

!!! LSA1 of R3 !!!

  LS age: 54

  Options: (No TOS-capability, DC)

  LS Type: Router Links

  Link State ID: 10.255.255.3

  Advertising Router: 10.255.255.3

  LS Seq Number: 80000006

  Checksum: 0xE3E9

  Length: 60

  Number of Links: 3

    Link connected to: a Stub Network

     (Link ID) Network/subnet number: 10.255.255.3

     (Link Data) Network Mask: 255.255.255.255

      Number of TOS metrics: 0

       TOS 0 Metrics: 1

    Link connected to: another Router (point-to-point)

     (Link ID) Neighboring Router ID: 10.255.255.2

     (Link Data) Router Interface address: 10.0.23.3

      Number of TOS metrics: 0

       TOS 0 Metrics: 100

    Link connected to: a Stub Network

     (Link ID) Network/subnet number: 10.0.23.0

     (Link Data) Network Mask: 255.255.255.0

      Number of TOS metrics: 0

       TOS 0 Metrics: 100

R2# show ip ospf database network

            OSPF Router with ID (10.255.255.2) (Process ID 1)

        Net Link States (Area 0)

!!! LSA2 of R2 !!!

  Routing Bit Set on this LSA

  LS age: 143

  Options: (No TOS-capability, DC)

  LS Type: Network Links

  Link State ID: 10.1.12.2 (address of Designated Router)

  Advertising Router: 10.255.255.2

  LS Seq Number: 80000005

  Checksum: 0xE019

  Length: 32

  Network Mask: /24

    Attached Router: 10.255.255.2

    Attached Router: 10.255.255.1

R2#

Notice the following:

  • R1 expresses its connection to the FastEthernet segment between R1 and R2 by R1's LSA1 referring to the DR's IP address 10.1.12.2. This is also the link-state ID (LSID) of the DR's LSA2. If you change the IP address of the DR, the LSA2 will change its link-state ID (LSID), as if the old router went away and new router came in. In other words, this change is not distinguishable from a topology change although the topology does not change at all, just the addressing changes. Notice that the LSA1 of R1 would need to change as well, as it would need to point to the updated LSA2 (DR's IP address).
  • In the same fashion, if you change any address on a router's interface, be it towards a transit network, a stub network, or a point-to-point connection (that is expressed as a duplet of point-to-point link and a stub network on this link), the router's LSA1 will change because any link indicated in an LSA1 contains the IP address of the router's interface on that link. Again, a new LSA1 potentially means a changed topology, so OSPFv2 won't be able to distinguish it from a mere addressing change, and will treat the updated LSA1 as a topology change even if the topology remained the same, just the addressing changed.

We could argue that if we did a very detailed comparison of the original and updated LSA, we would be able to recognize if the topology changed or just the addressing was modified but at the same time, it would mean that you are starting to look on the particular LSA not as an atomic topology element but rather as a collection of addressing attributes around an essential topology element. This is exactly what IS-IS does - it has separate TLVs for topology information and separate TLVs for addressing information. If a new LSP about a router in IS-IS comes in and the TLVs comprising the topology information are the same as the ones already stored, the topology did not change and just the addressing needs to be updated, so you do not need to run SPF at all.

So the OSPFv2 authors took their lesson from IS-IS, and when they designed OSPFv3, they decided to do a similar thing - to separate topology and addressing information. The LSA1 and LSA2 in OSPFv3 contain absolutely no addressing information whatsoever. What they express is solely the topology of the network. If, on the same network, I start OSPFv3 in IPv6 and have a look at the LSDB, this is what comes out:

R2# show ipv6 ospf database router

            OSPFv3 Router with ID (10.255.255.2) (Process ID 1)

        Router Link States (Area 0)

!!! LSA1 of R1 !!!

  LS age: 572

  Options: (V6-Bit E-Bit R-bit DC-Bit)

  LS Type: Router Links

  Link State ID: 0

  Advertising Router: 10.255.255.1

  LS Seq Number: 80000008

  Checksum: 0x903E

  Length: 40

  Number of Links: 1

    Link connected to: a Transit Network

      Link Metric: 10

      Local Interface ID: 4

      Neighbor (DR) Interface ID: 5

      Neighbor (DR) Router ID: 10.255.255.2

!!! LSA1 of R2 !!!

  LS age: 558

  Options: (V6-Bit E-Bit R-bit DC-Bit)

  LS Type: Router Links

  Link State ID: 0

  Advertising Router: 10.255.255.2

  LS Seq Number: 80000009

  Checksum: 0x9F9C

  Length: 56

  Number of Links: 2

    Link connected to: another Router (point-to-point)

      Link Metric: 100

      Local Interface ID: 6

      Neighbor Interface ID: 7

      Neighbor Router ID: 10.255.255.3

    Link connected to: a Transit Network

      Link Metric: 10

      Local Interface ID: 5

      Neighbor (DR) Interface ID: 5

      Neighbor (DR) Router ID: 10.255.255.2

!!! LSA1 of R3 !!!

  LS age: 646

  Options: (V6-Bit E-Bit R-bit DC-Bit)

  LS Type: Router Links

  Link State ID: 0

  Advertising Router: 10.255.255.3

  LS Seq Number: 80000005

  Checksum: 0x472B

  Length: 40

  Number of Links: 1

    Link connected to: another Router (point-to-point)

      Link Metric: 100

      Local Interface ID: 7

      Neighbor Interface ID: 6

      Neighbor Router ID: 10.255.255.2

R2# show ipv6 ospf database network

            OSPFv3 Router with ID (10.255.255.2) (Process ID 1)

        Net Link States (Area 0)

!!! LSA2 of R2 !!!

  LS age: 562

  Options: (V6-Bit E-Bit R-bit DC-Bit)

  LS Type: Network Links

  Link State ID: 5 (Interface ID of Designated Router)

  Advertising Router: 10.255.255.2

  LS Seq Number: 80000004

  Checksum: 0x29B4

  Length: 32

    Attached Router: 10.255.255.2

    Attached Router: 10.255.255.1

R2#

Note how these LSAs express the underlying topology (R1 is connected to a transit network with R2 being a DR, R2 is connected via a point-to-point link to R3) but now, these LSAs have absolutely no address information present and the only remaining references are to RIDs of adjacent objects (routers, transit networks) which only resemble IP addresses but are not IP address at all.

Naturally, the addressing information must be stored somewhere - and it has moved out from LSA1 and LSA2 into LSA9, the intra-area-prefix LSA. Remember that in OSPFv2, both LSA1 and LSA2 contained IP addressing information. Therefore, if we take this information out from OSPFv3 LSA1 and LSA2 into an LSA9, this LSA9 must somehow indicate where does it "belong" -  whether it references the LSA1 or the LSA2 of a particular router. This is accomplished by three specific fields in the LSA9 - the referenced LSA type, referenced LSA ID, and referenced router ID.

My network has three routers (i.e. 3 LSA1) and one transit network (i.e. 1 LSA2). There shall be 4 LSA9, then. This is what the LSA9 look like in this network:

R2# show ipv6 ospf database prefix

            OSPFv3 Router with ID (10.255.255.2) (Process ID 1)

        Intra Area Prefix Link States (Area 0)

!!! LSA9 of R1 !!!

!!! The Referenced LSA Type and ID fields indicate to which LSA this

!!! LSA9 belongs; in this case, it is LSA1 (2001), LSID 0

!!! of the advertising router 10.255.255.1

!!! This LSA contains addresses that would have been in the related LSA1

!!! present as stub networks

  Routing Bit Set on this LSA

  LS age: 1483

  LS Type: Intra-Area-Prefix-LSA

  Link State ID: 0

  Advertising Router: 10.255.255.1

  LS Seq Number: 80000006

  Checksum: 0xE37E

  Length: 52

  Referenced LSA Type: 2001

  Referenced Link State ID: 0

  Referenced Advertising Router: 10.255.255.1

  Number of Prefixes: 1

  Prefix Address: FDFF::1 => Loopback <=

  Prefix Length: 128, Options: LA , Metric: 0

!!! LSA9 of R2 !!!

!!! The Referenced LSA Type and ID fields indicate to which LSA this

!!! LSA9 belongs; in this case, it is LSA1 (2001), LSID 0

!!! of the advertising router 10.255.255.2

!!! This LSA contains addresses that would have been in the related LSA1

!!! present as stub networks

  Routing Bit Set on this LSA

  LS age: 1470

  LS Type: Intra-Area-Prefix-LSA

  Link State ID: 0

  Advertising Router: 10.255.255.2

  LS Seq Number: 80000006

  Checksum: 0x8606

  Length: 64

  Referenced LSA Type: 2001

  Referenced Link State ID: 0

  Referenced Advertising Router: 10.255.255.2

  Number of Prefixes: 2

  Prefix Address: FD00:0:0:23:: => Serial Link R2-R3 <=

  Prefix Length: 64, Options: None, Metric: 100

  Prefix Address: FDFF::2 => Loopback <=

  Prefix Length: 128, Options: LA , Metric: 0

!!! LSA9 of R2's pseudonode !!!

!!! The Referenced LSA Type and ID fields indicate to which LSA this

!!! LSA9 belongs; in this case, it is LSA2 (2002), LSID 5

!!! of the advertising router 10.255.255.2

!!! This LSA contains addresses that would have been in the related LSA2

!!! present as transit networks

  Routing Bit Set on this LSA

  LS age: 1471

  LS Type: Intra-Area-Prefix-LSA

  Link State ID: 5120

  Advertising Router: 10.255.255.2

  LS Seq Number: 80000004

  Checksum: 0x215F

  Length: 44

  Referenced LSA Type: 2002

  Referenced Link State ID: 5

  Referenced Advertising Router: 10.255.255.2

  Number of Prefixes: 1

  Prefix Address: FD00:1:0:12:: => Ethernet Link R1-R2 <=

  Prefix Length: 64, Options: None, Metric: 0

!!! LSA9 of R3 !!!

!!! The Referenced LSA Type and ID fields indicate to which LSA this

!!! LSA9 belongs; in this case, it is LSA1 (2001), LSID 0

!!! of the advertising router 10.255.255.3

!!! This LSA contains addresses that would have been in the related LSA1

!!! present as stub networks

  Routing Bit Set on this LSA

  LS age: 1558

  LS Type: Intra-Area-Prefix-LSA

  Link State ID: 0

  Advertising Router: 10.255.255.3

  LS Seq Number: 80000005

  Checksum: 0xBECB

  Length: 64

  Referenced LSA Type: 2001

  Referenced Link State ID: 0

  Referenced Advertising Router: 10.255.255.3

  Number of Prefixes: 2

  Prefix Address: FD00:0:0:23:: => Serial Link R2-R3 <=

  Prefix Length: 64, Options: None, Metric: 100

  Prefix Address: FDFF::3 => Loopback <=

  Prefix Length: 128, Options: LA , Metric: 0

By splitting the LSA1 and LSA2 into LSA1+LSA9 and LSA2+LSA9 with LSA9 carrying all addressing information and LSA1/2 carrying only topology information, OSFPv3 now knows very easily when to run SPF and when not. If LSA1 and LSA2 don't change, then the topology does not change, and so there is no need to run SPF. An updated LSA9 is only a leaf change in the shortest path tree. OSPFv3 is therefore much more closer to IS-IS in terms of running the Partial Route Calculation than OSPFv2 was.

It has to be said, though, that because OSPF organizes its information in individual tiny LSAs, each of them having its own identity and standalone existence, you have now even more LSAs to individually store, synchronize, update, refresh, request, flood, age out... While this change has decoupled topology and addressing changes, it has also contributed to even more tiny LSAs and their types OSPFv3 has to take care of. Some people consider this to be a major scalability issue to OSPFv3 and look to IS-IS instead. While IS-IS also has its information organized in minuscule TLVs, these do not exist on their own, having their individual ID, sequence number, and age, rather, they are always refreshed and transmitted in a single LSP for a single router.

Could I kindly ask you to explain, what could they mean by associated transit network segement?

It's the LSA2 they refer to. Recall that while LSA1 and LSA2 formerly contained addressing information, OSPFv3 pulls that information out and stores it in a single type LSA9. So there are multiple LSA9 associated to different LSAs of the originating router - its LSA1, and - if the router is the DR - its LSA2 as well. OSPFv3, similarly to OSPFv2, recognizes two basic inter-router links: point-to-point links and transit networks. A point-to-point link is described by LSA1 only; a transit network is described by LSA2 of the DR plus LSA1 of all member routers pointing towards that LSA2.

Please feel welcome to ask further!

Best regards,

Peter

jan.hrnko Sat, 11/09/2013 - 09:01

Peter,

Thank you for your thorough and exhausting answer. It was extremely helpful, everything is crystal clear now :). Many thanks and keep up the great work!

Best regards,

Jan

david.beck Thu, 11/07/2013 - 12:56

What are your views about the use of ULAs?  When would you include them in an implementation? I can only see two compelling reasons to use them.

  1. If I believed a network was not completely secure by firewalls, I could imagine using ULAs on nodes that didn't need to access the outside world, but did need a routable addresses. That would add to those nodes security.
  2. Likewise, I see the usefulness of ULAs on the rare occassions when NAT66 is necessary.

Other than those two scenarios, I image implementing all networks with global addressing only. Am I missing something?

I was a bit surprised by your view that routable addresses assigned with SLAAC should basically be limited to the home, and that any business should be using DHCP. I'm hoping that the RA option to deliver DNS information will be widely implemented, and assume that DHCP will not be needed in many networks.  Most small to medium size businesses aren't currently interested in tracking which MAC address has been assigned which IP address. The logs, if kept at all, aren't kept long. I believe this is the situation for a huge number of companies, and that they will have no compelling reason to implement DHCPv6 to assign addresses to nodes. Please tell me what I'm missing and why I'm wrong.

Thanks for the excellent session.

fazainusa Fri, 11/08/2013 - 01:42

Peter,

We are seeing some strange behaviour on Vlan. The PC's are getting many IPV6 address....

Is this a bug?

Due to confidential data I have sent you the PM. Please lookinto this as this ...

regards

Fari

Peter Paluch Sat, 11/09/2013 - 08:20

Hello Fari,

I think your issue is illustrative enough to be interesting for other readers of this forum so with your kind permission, I will post sanitized parts of your configuration with changed addresses, and I will try to respond here.

In general, you have stated that in one of your VLANs, your IPv6-related configuration is as follows:

interface Vlan3
 ipv6 address fd00:1:10:1::1/64
 ipv6 nd reachable-time 600000
 ipv6 nd router-preference High
 ipv6 ospf 65000 area 3

and the problem is that stations in this VLAN exhibit multiple IPv6 addresses, as follows:

IPv6 Address. . . . . . . : fd00:1:e0:2010:c4b3:4a81:472:481d(Preferred)

IPv6 Address. . . . . . . : fd00:1:10:1:c4b3:4a81:472:481d(Preferred)

Temporary IPv6 Address. . : fd00:1:e0:2010:fc35:3979:2852:23f3(Preferred)

Temporary IPv6 Address. . : fd00:1:e0:2010:a18b:448:69b:9c3f(Deprecated)

Temporary IPv6 Address. . : fd00:1:e0:2010:a593:a0cb:c393:c864(Deprecated)

Temporary IPv6 Address. . : fd00:1:e0:2010:2109:c8c3:1dec:1128(Deprecated)

Temporary IPv6 Address. . : fd00:1:e0:2010:5d3a:63c8:22a5:dd5d(Deprecated)

Temporary IPv6 Address. . : fd00:1:e0:2010:756a:d277:9a33:ed3e(Deprecated)

Temporary IPv6 Address. . : fd00:1:e0:2010:9136:419c:6a5a:6068(Deprecated)

Temporary IPv6 Address. . : fd00:1:10:1:fc35:3979:2852:23f3(Preferred)

Temporary IPv6 Address. . : fd00:1:10:1:a18b:448:69b:9c3f(Deprecated)

Temporary IPv6 Address. . : fd00:1:10:1:a593:a0cb:c393:c864(Deprecated)

Temporary IPv6 Address. . : fd00:1:10:1:2109:c8c3:1dec:1128(Deprecated)

Temporary IPv6 Address. . : fd00:1:10:1:5d3a:63c8:22a5:dd5d(Deprecated)

Temporary IPv6 Address. . : fd00:1:10:1:756a:d277:9a33:ed3e(Deprecated)

Temporary IPv6 Address. . : fd00:1:10:1:9136:419c:6a5a:6068(Deprecated)

I would need to know more about the configuration of the Windows station in question. However, it seems that this computer either has two IPv6 addresses configured statically on the same interface, one with the fd00:1:e0:2010::/64 prefix and the other with fd00:1:10:1::/64 prefix, or it has received both these addresses via DHCPv6. The first thing to check therefore is whether these two non-temporary IPv6 addresses are correctly present or if there is a configuration glitch causing this particular Windows station to have two addresses.

The number of temporary addresses shown here is somewhat surprising to me but nonetheless, as you can see, all temporary addresses can be divided into two sets, each having a prefix derived from the particular non-temporary address. In addition, in each of these sets, only one temporary address is in the preferred state, others are deprecated.

This would roughly correspond to normal Windows 7 operation for IPv6. For each configured (or RA-discovered) IPv6 prefix, they create a random IPv6 address using this prefix (RFC 4941 Privacy Extensions). This prefix has two time variables controlling its usefullnes - the valid and the preferred time. The valid time is the total time the address is in existence. The preferred time is the time during which this IPv6 address can be used both to accept connections, and to initiate new connections. After the preferred time expires, the address is moved into the deprecated state that allows it to gracefully continue communicating in open sessions but it does not allow it to open new sessions, and a new random address is generated that will be moved to the preferred state. The amount of existing deprecated addresses shown here suggests that, relatively, the valid lifetime is significantly longer than the preferred lifetime. Please keep in mind that the default times in RA messages on Cisco routers are: preferred=604800 seconds (7 days), valid=2592000 seconds (30 days), so if the Windows followed these default settings, there should have been at most 5 temporary addresses present, 4 deprecated and one preferred.

Check out the following document for a very nice explanation of the address states:

http://msdn.microsoft.com/en-us/library/aa917171.aspx

At this point, I do not see a reason for a major concern. However, I certainly suggest double-checking whether the two non-temporary IPv6 addresses on this computer are correct. In addition, I suggest checking the show ipv6 routers vlan3 command on your multilayer switch to see if there are any other routers reported. I assume that the only router in the VLAN 3 is the multilayer switch whose configuration you have sent me, so this output should not reveal any more routers. I will also try to find out if there is a quick way of displaying the preferred/valid times of temporary addresses in Windows 7 so we can check your settings more closely.

I hope to follow up on this thread soon.

Best regards,

Peter

Peter Paluch Fri, 11/08/2013 - 06:19

Hi David,

There is a nice discussion about using the ULA addresses in the following document. Specifically see the section Addressing with Unique Local Addresses on Page 11 of the document.

http://www.cisco.com/en/US/docs/solutions/CVD/Aug2013/CVD-IPv6AddressingWhitePaper-AUG13.pdf

In general, however, if you already have an adequately sized global unicast address block and you are fine with using it inside your network then implementing the ULA along or instead this global block probably does not make much sense. What the ULA can give you is a stability in internal addressing if you expect certain renumberings. With multiple IPv6 addresses configurable on a single interface, you can deploy both ULA and global unicast addresses in your network, and while the global addressing may change over time, the ULA addresses may stay the same. You would not even need NAT for this, as operating systems can be tuned to select different source IPv6 addresses based on the destinations they talk to, so you could make your entire intra-company communication to use ULA addresses while for outbound communication, you would resort to using public addresses.

Think of it this way: if you want to run IPv6 in a network that is not connected to internet and for which you have no official global unicast address space, what address space should you use? Of course you could simply use just about any space as long you are disconnected from internet, but as soon as you connect to internet you will need to completely renumber the network because you wouldn't otherwise be able to communicate with those parts of internet whose scope you are overlapping. With ULA, it is somewhat different: you assign ULA addresses, and when you get connected to internet, you can add global unicast addresses instead of removing the old addressing infrastructure, possibly breaking lots of things in progress. Even if you are never going to connect your network to live internet, it is always a soothing feeling (and an expression of well-developed network aesthetics, as Jeff Doyle would put it ) to use an address scope designated for that very purpose.

And of course, with Network Prefix Translation per RFC 6296, you can use ULA just like RFC 1918 addresses.

But as I said earlier - if you can sufficiently protect your network using firewalls, and you are fine with using global addressing throughout your enterprise (assuming you have an official global IPv6 prefix), there is no special need to deploy ULA at all.

I was a bit surprised by your view that routable addresses assigned with  SLAAC should basically be limited to the home, and that any business  should be using DHCP. 

I think I was not that strict - what I wrote is: "In more controlled environments, the DHCP is a must." But I get your point.

I'm hoping that the RA option to deliver DNS information will be widely  implemented, and assume that DHCP will not be needed in many networks.   Most small to medium size businesses aren't currently interested in  tracking which MAC address has been assigned which IP address. The logs,  if kept at all, aren't kept long. I believe this is the situation for a  huge number of companies, and that they will have no compelling reason  to implement DHCPv6 to assign addresses to nodes. Please tell me what  I'm missing and why I'm wrong.

The support for RA DNS option is rather poor so far. Many businesses routinely run on DHCP for their IPv4 infrastructure so suddenly going in the SLAAC direction can be foreign to them. Also, as I explained in my response to Tenaro, the RA mechanism has a limited scope of options deliverable to a client and IETF probably won't be making it a universal vehicle for all possible settings. If you need to convey more advanced or less typical settings to a client, the RA simply isn't a mechanism to do this. Just think of lightweight access points trying to learn the IPv6 address of their wireless controller. Or IP phones looking for the IPv6 address of their TFTP/UCM server. Or even simple Windows stations requesting the IPv6 address of their NTP server. Do we want to make RAs that customized and specific?

I admit that most businesses do not intend to track which MAC addresses have been assigned which IPv6 addresses, but that's not the exact point. The point is that in a network running SLAAC, you have simply no clue who is who, apart from the router and statically configured stations. Think of an IPv6 address from your own network sending out spam or trojans using your e-mail server. That IPv6 address is from your internal network but otherwise random, and you have, let's be modest, 10-20 stations. To verify even those few stations carefully for any infection or infiltration is tedious at best, and when this number of stations grows... you can see where I am heading. And when a police comes in saying that there has been an inappropriate content being shared from some station, or it was hosting an illegal sharing of licensed software and ask you to hand the station to them - how are you going to find out which station it is or was? You see, as network administrators, we are the first ones held accountable for its misuse. If something goes wrong and I do not even know where the attacker is, although it is somewhere inside my network with hundreds of stations, that can get very nasty. Even doing simple traffic and usage monitoring based on station's IPv6 address is practically impossible with randomized IPv6 addresses.

I guess what I am saying that if you need to have a true control over your network, not just a laissez-faire approach of "guys, just use this /64 prefix and off you go!", then SLAAC can backfire on you.

Thanks for the excellent session.

Thank you - I am honored. If it is excellent, it is thanks to you asking such insightful questions.

Best regards,

Peter

huangedmc Sat, 11/09/2013 - 07:13

hi Peter,

My organization doesn't currently use IPv6, and I'd like to propose two changes to make our network more secure:

1. Disable IPv6 protocol on managed workstations via Windows GPO, or Altiris

2. Block v6-v4 tunnels on perimeter firewalls

Do you think these are justified, or a waste of our time?

1. Disable IPv6 protocol on managed workstations via Windows GPO

It's possible a malicious internal user can set up his/her endpoint as default gateway, and become man in the middle to gather everyone else's data. (I'm surprised nobody has tried to say "woman in the middle" for those die hard women's rights fans :0)

There are some IPv6 L2 security solutions that we can implement, such as RA Guard, but we have many different hardware & software versions, so don't think all of them support those features.

Also I don't want to introduce management overhead to our existing network infrastructure.

I'd rather achieve the goal by having someone else (Desktop team) do it.

Would those IPv6 first hop security features work when we don't have IPv6 routing turned on anyway?

I assume they would, since most of them sound like they're done in L2 / local broadcast domain on L2-only access switches.

============================

2. Block v6-v4 tunnels on perimeter firewalls

Users may have these tunnels out to the Internet, which bypass our v4 security policies / ACL's.

My understanding is these workstations are completely volnerable, by exposing themselves out there, w/o the protection of our firewall.

Would blocking IP protocol 41 achieve what I want to do?

============================

Just to clarify I'm not trying to bash IPv6.

It is a good solution for certain scenarios.

It's just that implementing IPv6 the right way has many implications...getting senior management's buy-in, coordination w/ all departments, hardware/software upgrades & purchase, training, testing, making sure all app's work, etc.

We just don't have a need & the resources for it right now.

thanks in advance for your response.

Peter Paluch Sun, 11/10/2013 - 09:42

Hi,

Thanks for joining! Funny - I didn't think I would be be giving hints about disabling IPv6 in a thread about IPv6 routing protocols

If I understand you correctly, within your particular enterprise, the IPv6 connectivity could subvert your current security policies, and you currently do not have sufficient resources to do the IPv6 connectivity right, and so you want to stop it rather than have it running awild. There is no doubt - an IPv6 tunnel could indeed allow an outside world to access your internal machines, native IPv6 connectivity could do that even more so.

While I am not the one to encourage disabling IPv6 (and I know you are not, either), if you really need to stop IPv6 from working, both approaches you are suggesting are sensible. Disabling IPv6 on Windows may be tricky. It is not sufficient just to unbind the IPv6 from particular interface because internally, Windows will still be using IPv6. This article will certainly be helpful:

http://support.microsoft.com/kb/929852

Using RA guard or simply ACLs capable of stopping all IPv6 packets on switches would also be advisable (if IPv6 filtering is supported, configuring an IPv6 ACL with deny ipv6 any any should be trivial; if filtering based on EtherType is supported then IPv6 is identified by the 0x86DD value; on 2960 and higher Catalysts, VLAN ACLs would be ideal for this purpose).

As for blocking the tunnels, most certainly, blocking IPv4 protocol 41 is the main course of action. In addition, TEREDO tunnels use UDP encapsulation towards destination port 3544; blocking this destination port would be sensible as well.

Please feel welcome to discuss this issue further!

Best regards,

Peter

sarah.staker Tue, 11/12/2013 - 13:42

Hello Peter,

Why do we need to configure IPv4-alike router identifiers with EIGRP for IPv6 and OSPFv3 when both these protocols are based on IPv6?

thank you,

Sara S.

Peter Paluch Wed, 11/13/2013 - 07:56

Hi Sarah,

Thank you for joining!

First and foremost, both EIGRP and OSPFv3 have a concept of a unique router identifier - a number that is used inside these protocols' messages for various purposes, primarily to sign a piece of routing information by its originator, or to allow routers to refer to each other by their identifiers, regardless of the addresses being used. The router ID, or simply RID, does not replace IP (or IPv6) addresses, and is not used as an IP address; it merely helps routers to see and recognize each other using a single number rather than doing a fairly tiresome task of keeping a list of all addresses belonging to a particular router.

From this viewpoint, the RID can be any arbitrary number, as long as it is unique among routers. Quite naturally, with IPv4 EIGRP and OSPFv2, it was logical to choose one IP address per router as the RID, as all IP addresses used in a network are unique. This was the reason that both EIGRP and OSPFv2 started using 4B-long RIDs that can be readily initialized using an IPv4 address, though a RID is never used as an IP address by these routing protocols. To make the RID easily readable, it is written just like an IP address, octet per octet, but still, an RID is not an IP address.

When EIGRP for IPv6 and OSPFv3 came, they could have changed the RID from 4B to 16B and used IPv6 addresses as initial values in the RIDs. However, this would not really be helpful. Because the RIDs are not IPv4 addresses, they do not obey any addressing rules or classes, and they can (usually) go from 0.0.0.1 up to 255.255.255.254 (the lowest and highest may be reserved for specific purposes). This allows for almost 2^32 unique RIDs, far more than the maximal number of routers you could ever possibly have in a network. So the 4B RID numbering space is large enough to accomodate all reasonable networks, and there is no compelling reason for these protocols to move from 4B RID to 16B RID.

So what you configure with EIGRP for IPv6 and with OSPFv3 are not IPv4 addresses in RIDs - rather, you assign these routers unique 4B long numbers that uniquely identify them in a protocol-independent manner. While the format of RIDs could have changed in these protocols, it would be useless.

Anyone interested please feel welcome to ask further!

Best regards,

Peter

jan.hrnko Wed, 11/13/2013 - 09:38

Hi Peter,

I would like to ask you yet another question that I was discussing with a colleague. We would like to know what is your view on the matter, if you would be so kind and share your insights with us we would be most thankful.

IPv6 introduces new type of address - anycast. Is there any special technique related to anycast routing or are the prefixes injected into common routing protocols (maybe OSPFv3, EIGRP) and then redistributed into BGPv6?

One more thing - hope you don't mind it as I am sure that you are reading/hearing a lot of this constantly, but we have seen something similar going on in IPv4 world with google DNS servers for example - correct me if I am wrong. Of course, this thread does not cover IPv4 and I don't want to be off topic but what do you think about that? Could they be just redistributing same IP into BGP in different places? Wouldn't that be "incorrect" as these addresses wouldn't be unique and we don't have concept of anycast in IPv4? I just can't put my finger on it.

The reason I mentioned the google dns servers example is that I can imagine how does it work when we send some single queries using UDP (but even DNS can make use of TCP - I don't know if google dns works with TCP as well) but what about TCP in IPv6? How do we treat TCP connection using anycast destination address? I mean, when load balancing or asymmetric routing comes in play, how can we ensure (or even enforce?) communicating with a single server? I assume that this is done by the server responding with its unicast address but couldn't that somehow be a security threat (man in the middle - somebody else responding with its ucast src addr) or will the IPv6's security prevent that?

And how do the routers route such packets? Do they send the packets to multiple destinations or do they pick just the closest one, like when same prefixes+masks are advertised with different metrics?

Sorry for such a huge amount of quite basic questions but I wasn't able to find satisfactory answers so far. Maybe I should read some RFCs first :). Thank you very much for the time and knowledge that you are sharing with us.

Best regards,

Jan

jeleinweber Thu, 11/14/2013 - 08:03

Anycast is used with v4 too; it's not just a v6 concept.  You'll have to wait for Peter's answer on the OSPFv3/EIGRP stuff, but the general idea is indeed to advertise the anycast address from multiple sites in BGP.  TCP connections only break if the routing topology changes during the lifetime of the connection, which can be an issue if any intermediate hop is flapping, but you could have the same issue with a multi-packet UDP stream e.g. with anycast or multicast multimedia flows.  Anycast is a wide-area version of load balancing; typically within a data center you'd use something else.  An anycast packet is normally delivered to just one of the set of possible hosts, based on BGP's metric of "nearest", in contrast to multicast packets which are delivered to all of them.  This is equally true in v4 and v6.  The major difference in v4 and v6 next-hop behaviors is that for on-link vlan traffic v4 uses broadcast for ARP where v6 uses multicast for ND instead, and v6 expects to see RA's telling it which prefixes are on-link.  Once you hit a router the two protocols make similar kinds of decisions.  At layer 2 ethernet supports all three of unicast, multicast, and broadcast, which influenced the v6 design.

The anycast server response address choice is an issue; as you note with a source address response from the anycast address spoofing is an issue, but with a reponse from a different unicast address firewall blocking becomes an issue instead.  Implementations vary, which can be seen if you experiment with the now-deprecated 6to4 relays, where the anycast relay hosts are visible via 192.88.99.0/24 routes on v4 and via 2002::/16 routes on v6; you can find different relays which have chosen differently, and  in addition to the unicast versus anycast source address choice dilemma the round trip path is very likely to also be asymmetric and use different relays for the clients v4 choice and the servers v6 choice.  The resulting unreliability of end-to-end delivery (>15% failure rates in Geof Huston's tests for APNIC) would have killed off interest in 6to4 tunneling even without a scarcity of relays.

In the DNS case the ultimate client is usually talking to a nearby recursive resolver, and the resolver is depending on the identifier value in the packet to provide partial resistance to guessing attacks, and will accept replies from any address, precisely because it is expecting a high percentage of unicast responses from destinations which were originally anycast. Hence the security communities interest in seeing DNSSEC widely deployed for stronger assurance of correct DNS answers.

While I definitely encourage reading RFC's, they tend to be a bad way to begin gaining a general understanding, so by all means keep asking questions.

-- Jim Leinweber, WI State Lab of Hygiene

Peter Paluch Thu, 11/14/2013 - 15:26

Hi Jim and Jan,

Jim, thank you for joining and for your insightful answer. Rated as deserved. Jan, please be sure to check Jim's answer carefully - it has lots of very useful information. Jim, thank you!

Jan, as to your questions: While you could certainly inject /32 prefixes into an IGP and subsequently in BGP, I have encountered that as a practice. I have checked all 13 root servers' addresses on Route Views servers, and each of them are advertised as /24 prefixes. As you can imagine, this strongly depends on the individual ISP's configuration, especially related to route summarization/aggregation.

I have found a series of documents discussing the use of IPv4 anycast with DNS:

http://www.netlinxinc.com/netlinx-blog/45-dns.html?layout=default

Check out the Anycast DNS documents from this page.

The reason I mentioned the google dns servers example is that I can  imagine how does it work when we send some single queries using UDP (but  even DNS can make use of TCP - I don't know if google dns works with  TCP as well) but what about TCP in IPv6? How do we treat TCP connection  using anycast destination address? I mean, when load balancing or  asymmetric routing comes in play, how can we ensure (or even enforce?)  communicating with a single server?

Jan, keep in mind here that issues with asymmetric routing can occur even without anycast addressing. Anycast addressing does not really add to issues with asymmetric routing. As long as the routing stays constant, you as a particular station communicate with the topologically nearest anycast IP address, so for this particular moment in time, the communication is in fact unicast. Communicating with the same server is ensured as long as the routing does not change.

For routers, routing to anycast addresses is no different to routing towards unicast addresses. An anycast address is different by the way we use it, not by its contents. To routers, multiple sources advertising the same anycast address are simply multiples paths to reach the same destination - so each router will choose the shortest available path from its viewpoint.

As there are quite a few new things to think about in my and especially Jim's answer, I encourage you to think all of this over and please feel more than heartily welcome to ask further once you've gone through all of this.

Best regards,

Peter

jan.hrnko Sat, 11/16/2013 - 10:45

Hi Peter,

thank you once again for your insightful answer and also thank you for such a great session! Too bad it ended so soon but I hope there will be another one sometime soon ;-). Take care and thank you so much!!!

Best regards,

Jan

jan.hrnko Sat, 11/16/2013 - 10:39

Hi Jim,

Thanks for your insights and valuable answer.

Anycast is used with v4 too; it's not just a v6 concept.

Maybe I have used innapropriate terms, but what I thought was that IPv4 does not define nor recognize anycast address in any way. Yes, it is used in fashion that you described and I fully agree with that.

"Anycast addresses are syntactically indistinguishable from global unicast addresses because anycast addresses are allocated from the global unicast address space."

But:

"Anycast addresses must not be used as the source address of an IPv6 packet."

So that's why I said what I said. As I have seen, IPv4 always responds with the same source address (as it should, really) as well while IPv6 responds with its unicast address. To me IPv4 "anycast" is just a regular address that is being used in several places but does not have the true "nature" of IPv6 anycast addresses. Please, correct me if I'm wrong or if you disagree. I am most thankful for your response and opinion.

Thank you once again for your previous answer, it was very helpful.

Best regards,

Jan

Peter Paluch Sat, 11/16/2013 - 14:05

Hi Jan,

First of all, thank you for your immensely kind words!

"Anycast  addresses are syntactically indistinguishable from global unicast  addresses because anycast addresses are allocated from the global  unicast address space."


But:

"Anycast addresses must not be used as the source address of an IPv6 packet."

Oh, now I see the source of your doubts.

You are quoting the RFC 3513. You have to take the entire context into consideration. In particular, that RFC says in Section 2.6:

   There is little experience with widespread, arbitrary use of internet
   anycast addresses, and some known complications and hazards when
   using them in their full generality [ANYCST].  Until more experience
   has been gained and solutions are specified, the following
   restrictions are imposed on IPv6 anycast addresses:

   o  An anycast address must not be used as the source address of an
      IPv6 packet.

   o  An anycast address must not be assigned to an IPv6 host, that is,
      it may be assigned to an IPv6 router only.

Note the first paragraph: it says there is not enough experience with using anycast addressing. So while this RFC recognizes the category of anycast IPv6 addresses, at the same time it also states that it should not yet be used until more experiences is gained. In other words, the RFC 3513 does not say how the anycast addresses are supposed to work; rather, it defines them and at the same time, postpones their deployment to a later date.

This RFC is now obsoleted by RFC 4291. In this RFC, the restriction has been lifted. If you check it, the Section 2.6 no longer contains similar statements. In addition, the Appendix B where changes to RFC 3513 are documents explicitly states:

    o The restrictions on using IPv6 anycast addresses were removed
      because there is now sufficient experience with the use of anycast
      addresses, the issues are not specific to IPv6, and the GROW
      working group is working in this area.

In other words, according to RFC 4291, anycast IPv6 addresses are usable just like any other, and if you contact a device under its anycast address, it will respond back using that address.

Hopefully, this resolves some of your doubts.

Best regards,

Peter

jan.hrnko Sat, 11/16/2013 - 14:12

Hi Peter,

Oh, I see . Thank you so much for making this clear. Guess I should use diff next time I read RFCs . Thank you once again.

All the best,

Jan

Peter Paluch Fri, 11/15/2013 - 02:34

Hi John,

Thank you for joining! This is a very vast and philosophical question

As a networker, I am looking at the IPv6 as the natural evolution of IPv4. Extending the IP space, removing unused functionality, adding prospects for easier plug-and-play operation, streamlining a series of operations - this all seems to me to be a natural evolution of our views and requirements on a network layer protocol.

While I could try to name a couple of features in IPv6 and call them exciting, to me, IPv6 is a protocol that - in my personal view - is not something to bring totally unique features, unseen in IPv4; rather, it removes and adds features that extend the concepts first established in IPv4 so that they can go on being used in ever-increasing internet. Sorry if this is perhaps a disappointing view - but to me, IPv6 carries over a lot of ideas from IPv4 to actually make them live longer. We could have gone in totally different direction, similar the CLNP or other protocols quite different from IP, but IPv6 was designed with the idea of keeping the good features of IPv4, even though it is not directly compatible with it. The "excitement" results from keeping the smart ideas going

But nevertheless, if I were to name a few exciting concepts, I'd say: link-local addressing and the resulting "IP Unnumbered"-like operation of transit segments, SLAAC and truly plug-and-play connectivity (however, beware of hunting down unwanted routers in your network ), moving all IPv6 control protocols under IPv6 encapsulation and doing the necessary housekeeping - those would be my takes on the exciting things in IPv6.

Please feel welcome to ask further!

Best regards,

Peter

jeleinweber Fri, 11/15/2013 - 12:41

Vinton Cerf has taken to calling IPv4 the test version of the internet and IPv6 the production version, which is a great one sentence summary.  Since the most significant design goal of the "simple internet protocol plus" teams that coalesced to produce IPv6 was to be like IPv4, only with bigger addresses, we ended up with a familiar packet-switched network design with layered protocols, next hop routing, and best effort delivery.  The basic architecture is similar, the threat model is similar, lots is similar.  The importance of RA's, change from ARP to ND, and changes in DHCP are the biggest differences.

The most exciting aspect of IPv6 varies depending on the context.  Peter has well-described the policy wonks view.

* The ostensible benefit is the ability to grow the internet in the face of IPv4 address exhaustion. 

Note that breathless suggestions of 2^128 addresses are false; no one is likely to put more than 2^40 hosts on a subnet, and a desire to keep the prefix density ratio under 87% suggests limiting ourselves to less than 2^44 subnets.  It is true that if we replace IPv6 with some hypothetical future IPv10, it won't be because we ran out of addresses.  More likely because we designed IPv6 before the rise of the commercial internet taught us that we needed to engineer in better security from the start.  But don't expect to see over 2^40 hosts in your lifetime.

* For protocol designers, it's the deprecation of NAT and regaining of the end-to-end connectivity principle.  The violation of that principle by the existence of 500M v4 NAT devices - most of which will never see a firmware upgrade - is a horrible drag on v4 innovation.  Even if you ignore the new ideas we might hope to see, just wanting to scale hosts counts and network traffic up by a factor of 1000 or so in the next decade is highly likely to induce new flavors of congestion collapse, and the way to ameliorate those is by protocol innovation.  CPE NAT can't die too soon, and we really want native v6 to stamp out carrier-grade NAT44 too.

* For network engineers, it's the routing simplicity. All the subnets are the same size (/64), none of them are too small to accomodate whatever hosts you are trying to put on them, and the luxury of more prefix space means you can design sensible, simple, semantically meaningful topologies.  Better aggregation alone is yielding about a 7:1 reduction in advertised routes compared to v4.    With nearly any organization able to get a /48 prefix or bigger, the 16+ bits of subnetting makes your local sandwich shop scale like old-time v4 class-A holders such as MIT.  My v6 network is so much easier to describe and implement than my v4 network as a result.

For the average end-user, the IPv4 to IPv6 transition is a lot like the digital TV conversion: new equipment all around (maybe host hardware, certainly OS upgrades, wifi router, broadband modem, ...) in order to get the same old content.

-- Jim Leinweber, WI State Lab of Hygiene

Actions

Login or Register to take actions

Related Content

Discussions Leaderboard