国产91免费_国产精品电影一区_日本s色大片在线观看_中文在线免费看视频

您現(xiàn)在的位置: 通信界 >> 數(shù)據(jù)通信 >> 技術(shù)正文  
 
NAT-PT的設計與實現(xiàn)
[ 通信界 / 專網(wǎng)通信世界-中國電力通信網(wǎng) / m.6611o.com / 2006/7/2 11:16:48 ]
 

一、概述

  新的IPv6網(wǎng)絡的部署已經(jīng)在全球范圍內(nèi)展開,在此過程中我們不可能立即放棄原有的已經(jīng)成熟的IPv4網(wǎng)絡。在將來很長一段時間之內(nèi),兩種網(wǎng)絡必然是共存的,我們現(xiàn)在需要考慮的就是我們?nèi)绾文軌蚱椒(wěn)地從IPv4網(wǎng)絡過渡到IPv6網(wǎng)絡。

網(wǎng)絡地址和協(xié)議轉(zhuǎn)換(NAT-PT)就是我們的選擇之一,它能夠解決我們在過渡過程中所能碰到的一些問題。

二、NAT-PT介紹

  NAT-PT是一種純IPv6節(jié)點和IPv4節(jié)點間的互通方式,所有包括地址、協(xié)議在內(nèi)的轉(zhuǎn)換工作都由網(wǎng)絡設備來完成。支持NAT-PT的網(wǎng)關(guān)路由器應具有IPv4地址池,在從IPv6向IPv4域中轉(zhuǎn)發(fā)包時使用,地址池中的地址是用來轉(zhuǎn)換IPv6報文中的源地址的。此外網(wǎng)關(guān)路由器需要DNS-ALG和FTP-ALG這兩種常用的應用層網(wǎng)關(guān)的支持,在IPv6節(jié)點訪問IPv4節(jié)點時發(fā)揮作用。如果沒有DNS-ALG的支持,只能實現(xiàn)由IPv6節(jié)點發(fā)起的與IPv4節(jié)點之間的通信,反之則不行。如果沒有FTP-ALG的支持,IPv4網(wǎng)絡中的主機將不能用FTP軟件從IPv6網(wǎng)絡中的服務器上下載文件或者上傳文件,反之亦然。

  采用NAT-PT方式進行過渡的優(yōu)點是不需要進行IPv4,IPv6節(jié)點的升級改造,缺點是IPv4節(jié)點訪問IPv6節(jié)點的實現(xiàn)方法比較復雜,網(wǎng)絡設備進行協(xié)議轉(zhuǎn)換、地址轉(zhuǎn)換的處理開銷較大,一般在其他互通方式無法使用的情況下使用。

三、SIIT介紹

  在NAT-PT的實現(xiàn)中最重要的一部分就是協(xié)議部分的轉(zhuǎn)換算法,也就是無狀態(tài)IP/ICMP轉(zhuǎn)換算法(SIIT)。轉(zhuǎn)換方法包括如下幾個大的方面:

  IPv4->IPv6:
  ¨ IPv4頭部到IPv6頭部的轉(zhuǎn)換
  ¨ IPv4 UDP頭部的轉(zhuǎn)換
  ¨ IPv4的ICMP頭部轉(zhuǎn)換為IPv6的ICMP頭部
  ¨ IPv4的ICMP錯誤消息轉(zhuǎn)換為IPv6的ICMP錯誤消息

  IPv6->IPv4:
  ¨ IPv6頭部到IPv4頭部的轉(zhuǎn)換
  ¨ IPv4的ICMP頭部轉(zhuǎn)換為IPv6的ICMP頭部
  ¨ IPv4的ICMP錯誤消息轉(zhuǎn)換為IPv6的ICMP錯誤消息

  上述轉(zhuǎn)換中,IPv4頭部和IPv6頭部的相互轉(zhuǎn)換比較簡單,請參看RFC2765。下面重點描述一下IPv4->IPv6轉(zhuǎn)換過程中UDP頭部的轉(zhuǎn)換以及ICMP報文的轉(zhuǎn)換。

3.1、IPv4報文中UDP頭部的轉(zhuǎn)換

  在IPv4報文中,UDP頭部校驗和可以不填寫,即UDP頭部校驗和可以是0。但是在IPv6協(xié)議中,IPv6頭部沒有校驗和,為了保證UDP數(shù)據(jù)包的正確性,UDP頭部中校驗和字段必須填寫。

  如果一個UDP包被分片,但是UDP頭部的校驗和為0,作為一個無狀態(tài)的轉(zhuǎn)換設備來說,它不可能計算出一個有效的校驗和。不過,我們認為這種情況是惡意的攻擊。當轉(zhuǎn)換設備收到這種報文的時候,轉(zhuǎn)換設備應該丟棄該報文并生成一個系統(tǒng)相關(guān)事件(事件至少需要記錄IP地址和端口號)。

  如果轉(zhuǎn)換設備收到一個未分片的IPv4 UDP報文并且校驗和為0,轉(zhuǎn)換設備必須計算UDP校驗和,而且轉(zhuǎn)換設備應該記錄有多少個這樣的UDP校驗和被計算。

3.2、ICMP頭部的轉(zhuǎn)換

  在IPv6中,ICMP的校驗和計算包含一個偽頭部(源地址,目的地址,協(xié)議號,ICMP包長度),而在IPv4中,ICMP的頭部校驗和的計算不包含偽頭部。所以,所有經(jīng)過轉(zhuǎn)換設備的ICMP的校驗和都需要重新計算。

  說到ICMP頭部的轉(zhuǎn)換,除了校驗和之外,剩下的就是ICMP的Type值和Code值需要轉(zhuǎn)換,下面給出一個轉(zhuǎn)換表(表一),請大家參考。


3.3、ICMP錯誤消息的轉(zhuǎn)換

  對于ICMP錯誤消息,它頭部中的Type值和Code值的轉(zhuǎn)換也需要參照(表一)進行轉(zhuǎn)換。

  ICMP錯誤消息中包含了IP頭部,錯誤消息中的IP頭部也需要被轉(zhuǎn)換,就像普通的IP頭部被轉(zhuǎn)換一樣。轉(zhuǎn)換錯誤消息中的IP頭部可能導致數(shù)據(jù)包的長度變化,那么正常的IPv6頭部的有效載荷長度也需要更新。如圖一所示:
  ICMP錯誤消息中的IP頭部的轉(zhuǎn)換能夠第歸調(diào)用轉(zhuǎn)換外部IP頭部的轉(zhuǎn)換函數(shù)。只不過轉(zhuǎn)換之前,內(nèi)部的IP頭部中,源地址、目的地址和上層協(xié)議(TCP,UDP)的源端口號、目的端口號需要互換。只有這樣才能保證ICMP ERROR報文的正確轉(zhuǎn)換。

四、應用層網(wǎng)關(guān)(ALG)

4.1、DNS-ALG

  在組網(wǎng)的時候,如果處于V6網(wǎng)絡的主機需要連接到V4網(wǎng)絡中的主機,V6主機可以認為V4主機的所對應的IPv6地址為NATPT前綴+IPv4主機地址。如:V4主機地址為10.18.34.1,NATPT設備設定的前綴為2222::/64,則V4主機對應的IPv6地址就是2222::10.18.34.1或2222::0a12:2201。

  但是當V4網(wǎng)絡中的主機需要訪問V6網(wǎng)絡中的主機的時候就不能按照這種方法來做,V4主機可以按照V6主機所對應的域名來訪問,這就需要用到DNS-ALG功能。如(圖二)所示:
  V4端主機10.18.34.117需要訪問V6端主機2000::1,V4主機所對應的域名為www.ipv4.com.cn,V6主機所對應的域名為www.ipv6.com.cn

  首先V4主機發(fā)送DNS請求1給它的DNS服務器,請求www.ipv6.com.cn這個域名所對應的IPv4地址,V4的DNS服務器發(fā)現(xiàn)沒有這個資源記錄,于是它轉(zhuǎn)發(fā)這個DNS請求給V6的DNS服務器。需要注意到,NATPT設備上必須配置兩個DNS服務器的地址映射關(guān)系,如:10.18.34.252 => 2000::2,即V6的DNS服務器所對應的IPv4地址為10.18.34.252。

  NATPT發(fā)送經(jīng)過轉(zhuǎn)換的DNS請求2給V6的DNS服務器。

  V6的DNS服務器收到經(jīng)過NATPT設備轉(zhuǎn)換之后的DNS請求之后,它作出響應,發(fā)送DNS應答3給V4的DNS服務器。NATPT在收到應答3之后,對之進行轉(zhuǎn)換。因為www.ipv6.com.cn這個域名對應的IPv6地址為2000::1,所以應答報文中的資源記錄為AAAA,地址為2000::1,經(jīng)過轉(zhuǎn)換之后,資源記錄變?yōu)锳,2000::1這個IPv6地址所對應的IPv4地址就從地址池中獲取。假如獲取的IPv4地址為10.18.34.11,則在地址映射表中增加了一條新的地址映射表項2000::1=>10.18.34.11,此記錄為一動態(tài)記錄,超時之后將被自動刪除。

  NATPT設備發(fā)送經(jīng)過轉(zhuǎn)換之后的DNS應答報文給V4的DNS服務器。

  V4的DNS服務器收到應答報文之后在它的DNS緩存中增加一條記錄,表明www.ipv6.com.cn這個域名所對應的IPv4地址為10.18.34.11。在此之后,IPv4主機要和IPv6主機進行通信,只需要訪問IPv6主機的域名即可。

  從V6端訪問V4端主機的域名也按照同樣的步驟。

4.2、FTP-ALG

  當IPv4網(wǎng)絡中的用戶需要訪問IPv6網(wǎng)絡中的FTP服務器的時候,對應的FTP請求報文和相應報文需要進行轉(zhuǎn)換,F(xiàn)TP-ALG就是解決此問題的。一般來說,我們只需要對目的端口或源端口為21的TCP報文進行轉(zhuǎn)換,因為這些報文屬于FTP的控制報文,只有FTP控制報文中包含了地址和端口的信息。我們只需要轉(zhuǎn)換這些地址和端口。

  FTP的請求分很多類型,如PORT 、PASV、EPRT、EPSV等等。對于大多數(shù)支持IPv4的FTP客戶端來說,它們一般都只支持PORT和PASV請求模式,經(jīng)過升級之后可能支持EPRT和EPSV請求模式。但是現(xiàn)在支持IPv6的FTP客戶端一般是支持EPRT和EPSV這兩種請求模式。

  從上面的描述中我們可以知道,對于IPv4網(wǎng)絡中的FTP客戶端來說,它們即可以支持PORT和PASV請求模式也可以支持EPRT和EPSV請求模式。對于IPv6網(wǎng)絡中的FTP客戶端來說,它們肯定都支持EPRT和EPSV請求模式。但是,這時將會出現(xiàn)一個問題,如(圖三)所示:
  IPv4的FTP請求轉(zhuǎn)換成IPv6的FTP請求是二對一的關(guān)系,反之是一對二的關(guān)系。也就是說,我們現(xiàn)在需要考慮,在轉(zhuǎn)換IPv6側(cè)的FTP請求的時候我們應該怎么轉(zhuǎn)換呢?兩種都可以!但是兩種都有不足的地方。

  1、EPRT->PORT EPSV->PASV
  這種轉(zhuǎn)換中,F(xiàn)TP-ALG不能轉(zhuǎn)換“ EPSVALL“這種指令。這樣將導致FTP Server返回一個錯誤信息

  2、EPRT->EPRT EPSV->EPSV
  這種轉(zhuǎn)換要求IPv4側(cè)的主機升級FTP軟件以支持EPRT和EPSV兩種請求模式。

  鑒于這種情況,我們建議在缺省情況下采用第一種轉(zhuǎn)換方式,因為第一種轉(zhuǎn)換方式不需要IPv4側(cè)的主機進行升級,雖然有個指令不能轉(zhuǎn)換,但是我們認為該指令出現(xiàn)的幾率不是很頻繁,就算出現(xiàn)該指令,大多數(shù)情況下我們的FTP連接還是能夠建立起來,不影響文件的傳輸。我們還建議在NATPT轉(zhuǎn)換設備上設置一條命令,把IPv6側(cè)的FTP請求的轉(zhuǎn)換方式當作可配置的。

  在經(jīng)過FTP-ALG模塊轉(zhuǎn)換之后FTP報文的數(shù)據(jù)部分長度可能發(fā)生變化,此時TCP頭部的校驗和需要重新計算,同時TCP包中的Seq Number和Ack Number需要調(diào)整。

六、NATPT設備應用范圍的考慮

  NATPT只是作為IPv4網(wǎng)絡向IPv6網(wǎng)絡過渡的時候采用的一種手段,NATPT自身有一定的局限性,由于轉(zhuǎn)換相當耗費系統(tǒng)資源和時間,所以NATPT設備注定不能作為核心的設備,只能用于邊緣協(xié)議和地址的轉(zhuǎn)換。而且NATPT對于系統(tǒng)安全不能夠很好的支持,而系統(tǒng)安全這一點對于下一代網(wǎng)絡來將非常重要。所以網(wǎng)絡中采用NATPT設備只能暫時作為一種解決問題的方案。

七、總結(jié)
  本文簡單地描述了NAT-PT轉(zhuǎn)換中所需要注意的幾個方面,但要從真正實現(xiàn)NAT-PT協(xié)議的角度來講,這些遠遠不夠。武漢郵科院烽火網(wǎng)絡公司的Fengine系列路由器已經(jīng)實現(xiàn)了NATPT轉(zhuǎn)換,包括DNS-ALG、FTP-ALG、SIP-ALG等。能夠為用戶提供從IPv4到IPv6網(wǎng)絡平滑進行過渡的解決方案。眾所周知,在進行NATPT轉(zhuǎn)換之后,系統(tǒng)的性能將大大降低,但是烽火網(wǎng)絡公司的R8000系列路由器能夠?qū)崿F(xiàn)硬件的轉(zhuǎn)換,大大提高了NATPT的轉(zhuǎn)換性能和可靠性。

參考資料:
[FTP-IPV6] Allman, M., Ostermann, S. and C. Metz, "FTP Extensions for IPv6 and NATs", RFC 2428, September 1998.
[DNS-ALG] Srisuresh, P., Tsirtsis, G., Akkiraju, P. and A. Heffernan, "DNS extensions to Network Address Translators (DNS_ALG)", RFC 2694, September 1999.
[NAT-PT] George Tsirtsis., "Network Address Translation - Protocol Translation", RFC 2766, February 2000.
[SIIT] Nordmark, E., "Stateless IP/ICMP Translator (SIIT)", RFC 2765, February 2000.
[ICMPv4] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[ICMPv6] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6)", RFC 2463, December 1998.

 

作者:專網(wǎng)通信世界-中國電力通信網(wǎng) 合作媒體:專網(wǎng)通信世界-中國電力通信網(wǎng) 編輯:顧北

 

 

 
 熱點技術(shù)
普通技術(shù) “5G”,真的來了!牛在哪里?
普通技術(shù) 5G,是偽命題嗎?
普通技術(shù) 云視頻會議關(guān)鍵技術(shù)淺析
普通技術(shù) 運營商語音能力開放集中管理方案分析
普通技術(shù) 5G網(wǎng)絡商用需要“無憂”心
普通技術(shù) 面向5G應運而生的邊緣計算
普通技術(shù) 簡析5G時代四大關(guān)鍵趨勢
普通技術(shù) 國家網(wǎng)信辦就《數(shù)據(jù)安全管理辦法》公開征求意見
普通技術(shù) 《車聯(lián)網(wǎng)(智能網(wǎng)聯(lián)汽車)直連通信使用5905-5925MHz頻段管理規(guī)定(
普通技術(shù) 中興通訊混合云解決方案,滿足5G多元業(yè)務需求
普通技術(shù) 大規(guī)模MIMO將帶來更多無線信道,但也使無線信道易受攻擊
普通技術(shù) 蜂窩車聯(lián)網(wǎng)的標準及關(guān)鍵技術(shù)及網(wǎng)絡架構(gòu)的研究
普通技術(shù) 4G與5G融合組網(wǎng)及互操作技術(shù)研究
普通技術(shù) 5G中CU-DU架構(gòu)、設備實現(xiàn)及應用探討
普通技術(shù) 無源光網(wǎng)絡承載5G前傳信號可行性的研究概述
普通技術(shù) 面向5G中傳和回傳網(wǎng)絡承載解決方案
普通技術(shù) 數(shù)據(jù)中心布線系統(tǒng)可靠性探討
普通技術(shù) 家庭互聯(lián)網(wǎng)終端價值研究
普通技術(shù) 鎏信科技CEO劉舟:從連接層構(gòu)建IoT云生態(tài),聚焦CMP是關(guān)鍵
普通技術(shù) SCEF引入需求分析及部署應用
  版權(quán)與免責聲明: ① 凡本網(wǎng)注明“合作媒體:通信界”的所有作品,版權(quán)均屬于通信界,未經(jīng)本網(wǎng)授權(quán)不得轉(zhuǎn)載、摘編或利用其它方式使用。已經(jīng)本網(wǎng)授權(quán)使用作品的,應在授權(quán)范圍內(nèi)使用,并注明“來源:通信界”。違反上述聲明者,本網(wǎng)將追究其相關(guān)法律責任。 ② 凡本網(wǎng)注明“合作媒體:XXX(非通信界)”的作品,均轉(zhuǎn)載自其它媒體,轉(zhuǎn)載目的在于傳遞更多信息,并不代表本網(wǎng)贊同其觀點和對其真實性負責。 ③ 如因作品內(nèi)容、版權(quán)和其它問題需要同本網(wǎng)聯(lián)系的,請在一月內(nèi)進行。
通信視界
華為余承東:Mate30總體銷量將會超過兩千萬部
趙隨意:媒體融合需積極求變
普通對話 苗圩:建設新一代信息基礎設施 加快制造業(yè)數(shù)字
普通對話 華為余承東:Mate30總體銷量將會超過兩千萬部
普通對話 趙隨意:媒體融合需積極求變
普通對話 韋樂平:5G給光纖、光模塊、WDM光器件帶來新機
普通對話 安筱鵬:工業(yè)互聯(lián)網(wǎng)——通向知識分工2.0之路
普通對話 庫克:蘋果不是壟斷者
普通對話 華為何剛:挑戰(zhàn)越大,成就越大
普通對話 華為董事長梁華:盡管遇到外部壓力,5G在商業(yè)
普通對話 網(wǎng)易董事局主席丁磊:中國正在引領全球消費趨
普通對話 李彥宏:無人乘用車時代即將到來 智能交通前景
普通對話 中國聯(lián)通研究院院長張云勇:雙輪驅(qū)動下,工業(yè)
普通對話 “段子手”楊元慶:人工智能金句頻出,他能否
普通對話 高通任命克里斯蒂安諾·阿蒙為公司總裁
普通對話 保利威視謝曉昉:深耕視頻技術(shù) 助力在線教育
普通對話 九州云副總裁李開:幫助客戶構(gòu)建自己的云平臺
通信前瞻
楊元慶:中國制造高質(zhì)量發(fā)展的未來是智能制造
對話亞信科技CTO歐陽曄博士:甘為橋梁,攜"電
普通對話 楊元慶:中國制造高質(zhì)量發(fā)展的未來是智能制造
普通對話 對話亞信科技CTO歐陽曄博士:甘為橋梁,攜"電
普通對話 對話倪光南:“中國芯”突圍要發(fā)揮綜合優(yōu)勢
普通對話 黃宇紅:5G給運營商帶來新價值
普通對話 雷軍:小米所有OLED屏幕手機均已支持息屏顯示
普通對話 馬云:我挑戰(zhàn)失敗心服口服,他們才是雙11背后
普通對話 2018年大數(shù)據(jù)產(chǎn)業(yè)發(fā)展試點示范項目名單出爐 2
普通對話 陳志剛:提速又降費,中國移動的兩面精彩
普通對話 專訪華為終端何剛:第三代nova已成為爭奪全球
普通對話 中國普天陶雄強:物聯(lián)網(wǎng)等新經(jīng)濟是最大機遇
普通對話 人人車李健:今年發(fā)力金融 拓展汽車后市場
普通對話 華為萬飚:三代出貴族,PC產(chǎn)品已走在正確道路
普通對話 共享退潮單車入冬 智享單車卻走向盈利
普通對話 Achronix發(fā)布新品單元塊 推動eFPGA升級
普通對話 金柚網(wǎng)COO邱燕:天吳系統(tǒng)2.0真正形成了社保管
国产91免费_国产精品电影一区_日本s色大片在线观看_中文在线免费看视频

      成人h动漫精品| 日韩午夜中文字幕| 久久精品人人爽人人爽| 秋霞国产午夜精品免费视频| 一本大道久久精品懂色aⅴ| 久久久久国产精品麻豆| 久久精品国产秦先生| 制服丝袜一区二区三区| 亚洲一级在线观看| 欧美性色aⅴ视频一区日韩精品| 日韩毛片一二三区| 99re8在线精品视频免费播放| 日本一区二区三区四区在线视频 | 在线视频综合导航| 亚洲欧美日本在线| 91福利在线观看| 91精品视频网| 欧美亚洲另类激情小说| 麻豆国产欧美一区二区三区| 秋霞午夜av一区二区三区| 欧美日本视频在线| 日日夜夜一区二区| 91精品国产高清一区二区三区蜜臀 | 欧美三区在线视频| 亚洲123区在线观看| 依依成人精品视频| 欧美a级理论片| 欧美国产一区在线| 蜜臀精品久久久久久蜜臀| 免费在线观看一区二区三区| 国产一区二区三区观看| 风间由美一区二区三区在线观看| 成人午夜碰碰视频| 在线成人免费观看| 一区二区不卡在线视频 午夜欧美不卡在| 欧美一区二区三级| 国模冰冰炮一区二区| 欧美国产一区视频在线观看| 91在线你懂得| 视频一区中文字幕国产| 久久久久久久久久久电影| 成人app网站| 五月激情综合婷婷| 国产亚洲欧美日韩日本| 欧美亚洲综合另类| 国产在线精品一区二区三区不卡| 亚洲欧洲韩国日本视频| 欧美日韩电影在线| 成人美女视频在线看| 图片区小说区区亚洲影院| 国产午夜精品一区二区三区嫩草| 欧美性色欧美a在线播放| 精品中文av资源站在线观看| 国产精品成人午夜| 欧美一区二区二区| 色综合天天狠狠| 国产一区二区久久| 天天爽夜夜爽夜夜爽精品视频| 国产天堂亚洲国产碰碰| 337p亚洲精品色噜噜噜| 97久久超碰国产精品| 国内精品嫩模私拍在线| 亚洲成人黄色影院| 国产精品福利一区二区三区| 亚洲精品一区二区三区福利 | 青青草视频一区| 亚洲视频香蕉人妖| 久久久国际精品| 日韩精品中文字幕一区| 欧美自拍偷拍午夜视频| 99视频超级精品| 国产风韵犹存在线视精品| 日本在线不卡视频| 亚洲成av人在线观看| 亚洲乱码国产乱码精品精98午夜| 久久精品亚洲国产奇米99| 日韩情涩欧美日韩视频| 在线不卡免费欧美| 欧美日韩一级二级| 在线观看日韩毛片| 91久久精品国产91性色tv| 99天天综合性| 成人av在线观| 成人爽a毛片一区二区免费| 国产一区二区伦理片| 久久国产精品一区二区| 美国十次综合导航| 久久99精品视频| 免费观看30秒视频久久| 男人的j进女人的j一区| 青娱乐精品在线视频| 秋霞午夜鲁丝一区二区老狼| 蜜臀av性久久久久蜜臀av麻豆| 午夜不卡av在线| 日本中文字幕不卡| 另类中文字幕网| 国产一区二区不卡老阿姨| 国产一区二区三区四区在线观看| 韩国v欧美v日本v亚洲v| 国产精品456露脸| 成人av在线资源| 91在线小视频| 欧美性猛交一区二区三区精品| 欧美亚洲尤物久久| 69久久夜色精品国产69蝌蚪网| 欧美一区二区三区免费视频| 欧美mv日韩mv国产| 国产午夜三级一区二区三| 一区免费观看视频| 亚洲一区在线观看网站| 免费国产亚洲视频| 国产精品香蕉一区二区三区| av成人免费在线| 欧美日韩国产一二三| 日韩亚洲电影在线| 中文字幕乱码日本亚洲一区二区| 中文字幕一区二区三区在线观看 | 中文字幕欧美国产| ...中文天堂在线一区| 亚洲自拍都市欧美小说| 婷婷综合另类小说色区| 国产精品一区二区不卡| 91浏览器在线视频| 日韩欧美国产综合一区| 中文字幕亚洲不卡| 婷婷成人综合网| 床上的激情91.| 欧美日韩免费在线视频| 久久久久久一二三区| 亚洲一区在线看| 国产成人综合在线播放| 欧洲亚洲精品在线| 久久久久国产精品麻豆ai换脸 | 91精品久久久久久久久99蜜臂| 在线看不卡av| 99精品国产视频| 国产精品毛片大码女人| 国产精品不卡一区| 日韩精品一二三| 波多野结衣的一区二区三区| 欧美日韩一区视频| 国产精品人成在线观看免费 | 国产福利一区二区| 欧美在线视频日韩| 欧美激情在线一区二区| 日本欧美一区二区三区乱码| 99久久99久久综合| 久久先锋影音av鲁色资源网| 亚洲成人综合视频| 99视频在线观看一区三区| 久久综合久色欧美综合狠狠| 亚洲bdsm女犯bdsm网站| 91日韩在线专区| 亚洲国产精品v| 久久97超碰国产精品超碰| 精品视频123区在线观看| 一区在线播放视频| 成人性生交大片免费看中文网站| 日韩欧美国产午夜精品| 亚洲一区二区在线观看视频| 久久精品亚洲精品国产欧美 | 日韩一区二区免费电影| 亚洲资源中文字幕| 一本一道久久a久久精品| 国产精品伦一区二区三级视频| 激情综合色综合久久| 91精品中文字幕一区二区三区| 亚洲综合色噜噜狠狠| 91美女在线看| 中文字幕日本不卡| 成人av动漫网站| 国产精品婷婷午夜在线观看| 国产经典欧美精品| 国产亚洲一区二区在线观看| 精品一区二区三区蜜桃| 日韩欧美成人一区| 麻豆一区二区三| 精品国产乱码久久久久久1区2区| 蜜桃视频在线一区| 欧美大片在线观看一区二区| 免费看黄色91| 精品黑人一区二区三区久久| 久久国产精品无码网站| 久久丝袜美腿综合| 国产精品系列在线播放| 中文一区二区完整视频在线观看| 国产白丝网站精品污在线入口| 欧美国产精品一区二区三区| 成人性生交大片免费看视频在线| 国产亚洲欧美日韩日本| 成人永久免费视频| 亚洲女与黑人做爰| 欧美日韩久久一区二区| 日韩国产精品91| 精品对白一区国产伦| 国产福利精品一区| 亚洲黄色小说网站| 在线成人免费观看| 国产乱码字幕精品高清av| 国产精品久久99|