问题描述：
在IPv6 的环境下，路由器设备默认为桥接模式，域名登录存在访问不了的情况。
分析：
原来的IPv4环境：
浏览器进行IPv4+DNS解析 -----》 符合特定的域名，进行拦截回复----》DNS解析出地址，进行页面访问
现在IPv6+IPv4的环境:
浏览器进行DNS解析，则会分成如下4类
序号 |
IP |
DNS协议 |
|
1 |
IPv4 |
A(请求IPv4地址) |
|
2 |
IPv4 |
AAAA(请求IPv6地址) |
|
3 |
IPv6 |
A(请求IPv4地址) |
|
4 |
IPv6 |
AAAA(请求IPv6地址) |
如下为一个典型的访问过程，此台PC采用无线连接路由器，浏览器先是发出了3，再发出4，最后发出了2；纯IPv4的1，未发出。
针对每一种情况的处理策略上方案可不同，由于当前设备桥接模式下对IPv6的支持度一般，因此按如下进行：
序号 |
IP |
DNS协议 |
处理策略 |
1 |
IPv4 |
A(请求IPv4地址) |
拦截回复 |
2 |
IPv4 |
AAAA(请求IPv6地址) |
丢弃 |
3 |
IPv6 |
A(请求IPv4地址) |
拦截回复 |
4 |
IPv6 |
AAAA(请求IPv6地址) |
丢弃 |
按上面3-》4-》2的处理方式，这个完整的过程，仍需求12秒，虽然情况3已经做了优先的回复处理。具体报文如附件：
如果对于情况4，采用IPv6+A的回复方式，这种情况在有的设备会认为回复不合法，不断的进行请求，导致解析不了域名，因此选择丢弃是比较合理的。
参考报文如附件：
对于情况2，如果采用IPv4+A进行回复，可能会出现同上面情况4回复IPv6+A一样的结果：个别特殊的设备认为DNS回复不合法，一直进行请求，导致阻塞。
如下情况，浏览器一直没有发A的请求，但最终也能访问页面，大概率是因为没有回复，所以就采用了缓存中的地址，进行了登录。
参考报文如下：
代码处理过程
有线eth865x.c
interrupt_isr->interrupt_dsr_rx->is_skb_dns_packet 做判断
无线8192cd_rx.c
rtl_netif_rx->gothrough_brsrc->is_skb_dns_packet 做判断
再到统一的封装层wrapper.c
wrapper_que_retrieve->wrapper_up->is_dns_packet做判断
ether_input->bridge_input->apclient_dns_redirct做处理
DNS报文拦截
无线连接：这种情况比较好处理，由无线驱动转发至有线驱动报文出去，中间会经过bridge
有线连接：
桥接模式下：
所有的网口都被划到同一vlan中，以加速数据的转发
情况1：IPv4的报文，通过配置SW的ACL规则，可以导入到CPU进行处理
情况2：IPv6的报文，目前没有可行的配置方案进行处理。
路由模式下：
由于存在路由转发，所有报文都会进行处理。
修改后的结果
IPv6的环境下，AP模式下:
无线登录域名进行访问， 延迟在10秒左右，时间如上分析，取决于手机的浏览器、系统返回的具体时间。
有线登录域名进行访问，可能存在访问不了情况（大概率），因为router.cmdc.com的域名会被解析为公网的IP，可能是IPv4，也可能是IPv6。
IPv6的环境下，路由模式下:
略
后续的优化方案
WEB服务器支持IPv6，无论是在有线桥接模式下，或是AP模式下，下面客户端是通过有线或无线连接，都满足如下处理策略：
序号 |
IP |
DNS协议 |
处理策略 |
1 |
IPv4 |
A(请求IPv4地址) |
拦截回复：ipv4+A |
2 |
IPv4 |
AAAA(请求IPv6地址) |
拦截回复:ipv4+AAAA |
3 |
IPv6 |
A(请求IPv4地址) |
拦截回复:ipv6+A |
4 |
IPv6 |
AAAA(请求IPv6地址) |
拦截回复:IPv6+AAAA |