他进一步说明，因为Header长短不同，会直接对设备中塬厂设计可储存的TCAM(Ternary Content Addressable Memory)容量造成影响。例如IPv4可以放一百条ACL(Access Control List)检查规则，但是在採行Dual Stack网路架构之后，两种通讯协定位址都要检查，则可能只能存放五十条规则。

　　但实务上的差异究竟有多大，会随着实作(Implement)方式不同而变化，钱小山强调，基于诸多潜在影响因素，因此準备导入IPv6的第一步，必须先进行IT基础架构的评量(Assessment)。不仅是网路，针对作业系统、应用程式、各种不同端点设备等皆须包含其中，只要利用评量工具就可达成。但实际上效能才是Dual Stack佈建优劣的主要差异，然而目前全球IPv6功能验证模式仍趋向功能性验证而已，至于效能则须仰赖IT人员在先期测试区域观察实机运作来判断。

　　▲Cisco技术事业群客户解决方案架构师钱小山建议，企业端目前应该做的，是预先準备好IPv6需求开始出现时的因应措施，并且在先期测试区域中模拟，届时才不致让既有IPv4环境下的服务系统受到影响。

　　评量之后不仅要确认各环节皆可支援IPv6，应用系统同样是不可忽视的关键。IP配置、监控管理、安全等系统，皆需要能够支援IPv6，例如SOC(Security Operation Center)要能「看得懂」IPv6，才得以进行Trace Back、Security Check等动作。而这些并非一蹴可及，假设2015年会开始强制配置IPv6位址，势必现在就得开始实作导入，否则将来不及修改应用系统。

　　在此同时，新开发的程式专案则应该IPv4与IPv6皆支援，但长期以来网路界在讨论IPv6时，这一点却往往被忽略。钱小山观察，通常网路与应用系统大多是由两组技术人员分别负责，因此当网路团队在谈Dual Stack，许多应用系统的人非但不懂且认为事不关己，孰不知，应用系统更是重要的主角，须随之修改为IPv6。

　　假如应用程式伺服器已启用IPv6且对外提供服务，但应用程式本身却没经过修改，当用户端要连线存取时，仍旧在等待IPv4的连线回应，如此一来，即使各设备端点皆已启用IPv6也是枉然。钱小山提醒，其实很多细节在RFC标準文件中皆有说明，不论任何平台，程式码中撰写的指令皆要随之修改才能取得IPv6位址。诸如此类的细节，往往必须先行测试才得以逐一验证解决。

　　责任编辑：XFF