IPv4 to IPv6 transition thesis

black_flower1921 · ‎01-12-2014

Hi,

I'm doing Bachelor thesis, the subject is :"IPv4 to IPv6 Transition". I hope you give me titles of books you recommend.

Also,I'd be happy if you give me a few tips.

right now,i need a topology for each transition mechansim with the configuration commands .

and how to configure an IPv4/IPv6 host?

i've already finished CCNA exploration 1 and 2,and now i'm enrolled in a CCNA exploration 3 class.my instructor has not been trained yet on using IPv6 . so,the whole subject is new for me

i'm sorry if this message was badly written , because i'm not that good in english.

yours faithfully,

Marcin Latosiewicz · ‎01-13-2014

You should rather try the learning network

https://learningnetwork.cisco.com/index.jspa

black_flower1921 · ‎01-13-2014

i will,thank you

fred · ‎01-13-2014

You might consider the RFC series.

We have been thinking about what we originally called "IP Next Generation" and then called "IPv6" and the requirements for a transition for about 20 years. When we started, we thought about requirements, and over time we have described methodologies and experience with those methodologies. There is ongoing work, primarily in the IETF's IPv6 Operations Working Group (). The current "received wisdom" is probably summarized in RFCs 4213 (

http://www.ietf.org/rfc/rfc4213.txt) and 6180 (http://www.ietf.org/rfc/rfc6180.txt).

Walking through that history means walking through the following. Note that many of these are pretty old, and have been replaced or updated by other documents.

http://www.ietf.org/rfc/rfc1671.txt

1671 IPng White Paper on Transition and Other Considerations. B.

Carpenter. August 1994. (Format: TXT=17631 bytes) (Status:

INFORMATIONAL)

http://www.ietf.org/rfc/rfc1933.txt

1933 Transition Mechanisms for IPv6 Hosts and Routers. R. Gilligan, E.

Nordmark. April 1996. (Format: TXT=47005 bytes) (Obsoleted by

RFC2893) (Status: PROPOSED STANDARD)

http://www.ietf.org/rfc/rfc2185.txt

2185 Routing Aspects of IPv6 Transition. R. Callon, D. Haskin.

September 1997. (Format: TXT=31281 bytes) (Status: INFORMATIONAL)

http://www.ietf.org/rfc/rfc2893.txt

2893 Transition Mechanisms for IPv6 Hosts and Routers. R. Gilligan, E.

Nordmark. August 2000. (Format: TXT=62731 bytes) (Obsoletes RFC1933)

(Obsoleted by RFC4213) (Status: PROPOSED STANDARD)

http://www.ietf.org/rfc/rfc3574.txt

3574 Transition Scenarios for 3GPP Networks. J. Soininen, Ed.. August

2003. (Format: TXT=23359 bytes) (Status: INFORMATIONAL)

http://www.ietf.org/rfc/rfc3750.txt

3750 Unmanaged Networks IPv6 Transition Scenarios. C. Huitema, R.

Austein, S. Satapati, R. van der Pol. April 2004. (Format: TXT=48153

bytes) (Status: INFORMATIONAL)

http://www.ietf.org/rfc/rfc3904.txt

3904 Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks.

C. Huitema, R. Austein, S. Satapati, R. van der Pol. September 2004.

(Format: TXT=46844 bytes) (Status: INFORMATIONAL)

http://www.ietf.org/rfc/rfc4038.txt

4038 Application Aspects of IPv6 Transition. M-K. Shin, Ed., Y-G.

Hong, J. Hagino, P. Savola, E. M. Castro. March 2005. (Format:

TXT=69727 bytes) (Status: INFORMATIONAL)

http://www.ietf.org/rfc/rfc4213.txt

4213 Basic Transition Mechanisms for IPv6 Hosts and Routers. E.

Nordmark, R. Gilligan. October 2005. (Format: TXT=58575 bytes)

(Obsoletes RFC2893) (Status: PROPOSED STANDARD)

http://www.ietf.org/rfc/rfc4215.txt

4215 Analysis on IPv6 Transition in Third Generation Partnership

Project (3GPP) Networks. J. Wiljakka, Ed.. October 2005. (Format:

TXT=52903 bytes) (Status: INFORMATIONAL)

http://www.ietf.org/rfc/rfc4942.txt

4942 IPv6 Transition/Co-existence Security Considerations. E. Davies,

S. Krishnan, P. Savola. September 2007. (Format: TXT=102878 bytes)

(Status: INFORMATIONAL)

http://www.ietf.org/rfc/rfc5211.txt

5211 An Internet Transition Plan. J. Curran. July 2008. (Format:

TXT=17158 bytes) (Status: INFORMATIONAL)

http://www.ietf.org/rfc/rfc6157.txt

6157 IPv6 Transition in the Session Initiation Protocol (SIP). G.

Camarillo, K. El Malki, V. Gurbani. April 2011. (Format: TXT=32492

bytes) (Updates RFC3264) (Status: PROPOSED STANDARD)

http://www.ietf.org/rfc/rfc6180.txt

6180 Guidelines for Using IPv6 Transition Mechanisms during IPv6

Deployment. J. Arkko, F. Baker. May 2011. (Format: TXT=49679 bytes)

(Status: INFORMATIONAL)

http://www.ietf.org/rfc/rfc6219.txt

6219 The China Education and Research Network (CERNET) IVI Translation

Design and Deployment for the IPv4/IPv6 Coexistence and Transition.

X. Li, C. Bao, M. Chen, H. Zhang, J. Wu. May 2011. (Format: TXT=44774

bytes) (Status: INFORMATIONAL)

http://www.ietf.org/rfc/rfc6264.txt

6264 An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition. S.

Jiang, D. Guo, B. Carpenter. June 2011. (Format: TXT=31881 bytes)

(Status: INFORMATIONAL)

http://www.ietf.org/rfc/rfc6586.txt

6586 Experiences from an IPv6-Only Network. J. Arkko, A. Keranen.

April 2012. (Format: TXT=52062 bytes) (Status: INFORMATIONAL)

http://www.ietf.org/rfc/rfc6589.txt

6589 Considerations for Transitioning Content to IPv6. J. Livingood.

April 2012. (Format: TXT=68822 bytes) (Status: INFORMATIONAL)

fred · ‎01-13-2014

Sorry, I mentioned v6ops, but didn't give you the pointer.

http://datatracker.ietf.org/doc/search/?name=v6ops&rfcs=on&activedrafts=on&sort=

James Leinweber · ‎01-13-2014

On the subject of transition mechanisms the basic obstacels are that v4 and v6 don't interoperate, that translation from v4 to v6 is highly problematic, that legacy equipment isn't dual-stack capable, and that as a planet we're pretty much out of v4.

E.g. http://www.ietf.org/rfc/rfc4966.txt

Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status

Pretty much all of the "automatic" tunneling protocols such as 6over4, ISATAP, 6to4, and Teredo have been or are being deprecated due to bad operational experience, e.g.

http://www.potaroo.net/ispcol/2010-12/6to4fail.html

https://isc.sans.edu/diary/Microsoft+Teredo+Server+%22Sunset%22/16153

What is actually happening is:

* some ISP's are dual-stacking aggressively, and large chunks of their customer base are already v6-enabled.

* lagging ISP's are toying with "carrier-grade-NAT" as an delaying tactic

* some providers are going v6-only, with border NAT64+DNS64 translation of some kind to get to the legacy v4 internet. This includes several chinese ISP's and in the USA Verizon WIreless's LTE4 network. Although legacy v4 experience is between bad and mediocre in this scenario, the providers don't care, because the top destinations such as google, youtube, netflix, facebook etc. are already dual-stacked and perform well over native v6.

Note that in analogy to the HDTV transition in the US, the home user generally has to replace gear (windows XP hosts, wifi routers, broadband modems) to actually get live v6 once the ISP offers it.

In the datacenter the primary transition obstacle is lagging 3rd party application vendors; most enterprise grade network hardware, OS software, and middleware has supported dual-stack operations for a while now.

-- Jim Leinweber, WI State Lab of Hygiene

fred · ‎01-13-2014

"Note that in analogy to the HDTV transition in the US, the home user generally has to replace gear (windows XP hosts, wifi routers, broadband modems) to actually get live v6 once the ISP offers it."

Yes, but... If you have bought your PC/Mac/*nix device since 2007, you have already upgraded it. The devices that a residential user will find lagging are typically the game box, residential gateway, set-top box, IP-capable TV, or mobile telephone.

Xbox 1 is IPv6-capable, although the edition that just came out has issues; better, as with many things, to wait for a service pack. The issue on XBox 1 apart from its SLAAC implementation is that the applications don't support it.